【架构与设计】分布式数据库架构类别和主流方案-京东云开发者社区

## 一、分布式场景下数据库架构方式

### 1. Share nothing

顾名思义，就是什么都不共享。

Mysql 的分库分表和大部分的Nosql都是这样的方案，底层实际上完全分离，节点之间单独计算，不共享数据。

好处很明显，设计简单，扩展灵活，并行度较高。

缺点也很明显，跨分片查询困难，数据一致性难以保证。

能够实现强一致的只有zookeeper这种轻量级的分布式存储框架，但是它是牺牲了可用性的前提来保证的一致性，这也是Kafka和Dubbo这种主流中间件在逐渐抛弃zookeeper的原因，详见[Zab1.0](https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab1.0)。

### 2. Share disk（或者Share storage）

这其实是计算、存储分离的架构，上层由多个无状态的计算节点组成，他们共享统一管理的数据存储集群。

比如亚马逊的Aurora和阿里的PolarDB，都是采用这种架构方式。

下图为PolarDB的架构：

![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/4269029061/p861.png)

可以看到，上层计算节点完全分片，通过[RDMA（远程直接数据存取）](https://en.wikipedia.org/wiki/Remote_direct_memory_access)进行数据传输。下层由多个数据服务组成，并通过Parallel-Raft协议保证一致性。

这其实也是硬件发展过程中，网络I/O速度不断追上磁盘I/O速度的体现。

## 二、主流方案介绍

### 1. Mysql分库分表

Mysql通过mycat、sharding-jdbc等进行分库分表方案，从源头上说，这并非一种产品而是架构方案。

分库分表后主要问题有如下几方面：

首先是数据不在一起，所以**无二级索引**。

强需求二级索引场景下，可能需要自建二级索引。由此又带来**一致性问题**，因为索引和数据不在同一个节点上。那么不同节点间调用，至少发生一次网络IO，这就增加了**可用性问题**。

但是，好处是显而易见的。

方案成熟，知识获取、人才储备都非常容易，Mysql又极其稳定，相关方案可信度较高。

### 2. TiDB

国产开源数据库，属于Share nothing架构，高度兼容Mysql，水平弹性扩容，支持标准的ACID事务。

基于Raft协议，提供金融机构的100%数据强一致性保证，且提供auto-failover方案。

且内部提供Spark能力，所以同时包含了OLTP和OLAP特性。

相比较Mysql来说，硬件成本高，依赖SSD，部署组件多，运维难度高。但是国内很多大型项目采用了，并且提供了很多的踩坑经验。

对于数据库来说，索引、唯一约束、主键约束、外键约束、DDL等都依赖事务，在分布式数据库领域下，事务的核心在于可见性。

一致性和原子性有各种log、MVCC的方案来保证。但是可见性只能依赖于**分布式锁**或者分布式MVCC。

1. **分布式锁**实现上，如何解决分布式死锁是困难所在。
2. **分布式MVCC方案**，Mysql并没有暴露数据版本，所以想做MVCC，数据的实时合并非常困难。

针对这个问题，TiDB数据版本控制使用的是事务启动时获取的全局读时间戳。

下图是TiDB的架构：

![](https://download.pingcap.com/images/docs-cn/tidb-architecture-v3.1.png)

可以看到，整个服务由TiDB集群统一通过Mysql协议对外提供服务，存储集群由多个TiKV和TiFlash节点组成，而TiKV自身存在独立计算能力，且各个TiKV之间并不共享数据，所以属于为Share nothing架构。

### 3. PolarDB

云原生数据库，实现了计算节点(主要做 SQL 解析以及存储引擎计算的服务器)与存储节点(主要做数据块存储，数据库快照的服务器)的分离，提供了即时生效的可扩展能力和运维能力。

闭源产品，原理理解全靠官网介绍，介绍文档表示，各种对比领先TiDB、OceanDB等。

共享存储型数据库的特点，写节点只有一个，所以较好的保证事务特性，性能问题依靠SSD和高带宽网络这种高硬件标准来保证。