分布式架构 全面讲解分布式数据库架构设计特点

从图中可以看到分布式数据库三大组件：协调节点、数据节点、全局事务管理器。协调节点负责SQL解析转发，充当的是类似proxy的角色，数据节点负责计算和数据存储，全局事务管理器负责全局事务读一致性的保证。

下面分别介绍一下目前主流的分布式数据库的架构以及设计差异。

1.TiDB

TiDB是目前在互联网界风靡的一款分布式数据库，由PingCAP公司研发，由三大组件构成，底层TiKV Server是Github开源组件，是一个分布式的kv存储引擎，做数据存储，对应数据节点;上层TiDB Server由PingCAP公司研发，用作SQL解析和转发，对应协调节点;PD Server复制全局时间戳分配，对应全局事务管理器。下面列举了它的架构特点：

①轻量化，深受互联网公司喜爱，适合与容器进行集成，当前PingCAP公司也在做TiDB operator，将TiDB容器化。

②部署简便，基于Ansible Playbook实现自动化部署。

③实现了基于Region级别的raft复制，将数据表拆分成一个个的Region，Region一主两备基于raft协议做复制，同时Region还会根据负载情况进行合并和分裂，由PD Server进行负载均衡调度。

④使用隐藏列作为分布列，分布列不占用真实列，这样在进行数据修改时数据不需要进行重分布，大致原理是使用表名和主键前面加上前缀信息作为隐藏列，再使用该列进行hash分布。

⑤TiDB Server总体兼容MySQL语法，这个兼容并不是将MySQL Server直接拿过来使用，因为TiKV底层是kv的存储模型，所以TiDB在执行sql的时候需要做sql到kv的映射。

⑥TiKV可以看成一个大的数据池子，在物理机层面不存在哪个机器是主，哪个是备，所有机器都是主节点，热点数据会自动进行动态负载均衡，数据是动态移动的。

⑦总体借鉴了google spanner f1和bigtable的论文，PD Server实现了逻辑上的时间戳，谷歌论文也提出了原子钟的概念，从物理上保证事务号全局有序。

2.OceanBase

OceanBase是蚂蚁金服自研的分布式数据库，号称代码从第一行完全自研。最近ob也屡屡刷新新闻头条，刷榜TPCC官网测试结果，刷新天猫交易额和tps记录，不过金融行业比如银行的应用案例并不多，也许是银行和支付宝可能天然有鸿沟吧。ob架构比较特殊，下面介绍一下它的架构特点：

①最底层是ob server，每个ob server集成了总控服务、sql引擎、存储引擎和数据分区。

②上层是ob proxy，实现sql的路由，这个不止是应用到observer的路由，也有observer之间的路由。

③数据拆成一个个分区，每个分区做paxos复制，保证强一致，主分区宕机不可用会自动切换到备分区。

④checkpoint时间改变，将checkpoint周期拉长为1天，所有交易都落在内存，然后每天夜里去刷一次盘，redo日志实时记录，这样避免了随机写的性能损耗，只有顺序写，更像内存数据库，性能更好，这样也带来一些问题，比如宕机后恢复时间变长，还有查询刚刚做的修改需要先查基础数据，再去应用redo条目，得到最新数据。

⑤两阶段提交并不使用ob proxy节点充当协调者，而是将ob proxy路由到的第一个主数据分区作为协调者，同时两阶段提交的prepare和commit等信息会进行持久化，如果写协调节点宕机，那么备分区会启用，同时读取持久化信息，这个设计和一般的分布式数据库不太一样。

⑥集群维护一个partition cache，分区的分布信息会通过ob proxy在不同ob server间传递。

⑦ob最早的时候曾经开源过一段时间，随后基于它也诞生了cbase、obase这些产品。

3.GaussDB

华为GaussDB分为三个产品线，Gauss100前身是华为自研的内存数据库gmdb，目前已经开源，Gauss200是基于pgxc架构研发的OLAP分析型数据库，Gauss300是在200的基础上继续研发的HTAP数据库，这里主要介绍Gauss300数据库，Gauss300就是上图中典型的架构：

①协调节点负责sql解析、转发的同时也充当了两阶段提交的协调者的角色，协调节点上面存储有部分元数据信息，元数据需要在多个协调节点之间进行同步，如果协调节点宕机，会影响ddl相关操作，还可能造成两阶段提交的残留信息，需要有两阶段残留清理机制。

②数据节点通过quorum-based流复制实现高可用，主备数据节点是实例级别的，一个主节点就是一个主PG实例，一台机器可以有多个主数据节点。

③GTM复制分配全局事务id，GTM一主多备，GTM主备之间要同步gxid信息，而且是强同步，那么带来一个问题，备GTM节点宕机会造成主GTM不可用，造成全局可用性问题，这块华为将GTM的高可用转移到etcd中，将GTM生成的xid写入到etcd中，etcd自身就是一个高可用强一致的集群，这样就保证了GTM的高可用，主GTM宕机那么备GTM会接替，然后继续从etcd集群中读写事务号。

④GTM的事务号是批量分配的，如果在高并发的情况下，gxid如果一条一条分配则会有性能瓶颈，华为将事务号改为一次分配几万甚至几十万，避免了GTM事务号分配的瓶颈。

⑤事务id由32位改为64位。PG的事务号是32位的，最大到42亿，所以事务号在PG中是很珍贵的资源，用完了就会循环使用，循环使用会带来很多严重问题，华为将事务号由32位改为了64位，这样事务号根本不可能用尽，那么一次分配几十万也不足为奇了。

⑥为了提升性能，华为也正在研发gtm-lite功能，该功能可以实现本地事务不走GTM，因为生产环境大部分是本地事务，因而能大大提升性能。

⑦Gauss300是基于pgxc架构演进而来的，类似基于pgxc的还有亚信AntDB、腾讯TBase。

4.SequoiaDB

SequoiaDB是巨杉自主研发的分布式数据库，最初的应用场景主要是历史数据归档和非结构化数据存档，但是近期来巨杉也在积极开发oltp功能，包括研发GTM，支持MySQL协议等。下面介绍一下它的架构特点：

①包括协调节点、编目节点、数据节点、PG节点等。协调节点负责sql转发，编目节点存储元数据，数据节点存储真实数据，PG节点做sql引擎。

②巨杉数据库底层存储是NoSQL的，数据都是JSON格式进行存储，优点类似MongoDB。

③PG节点是将PG Server拿过来做sql存储引擎，支持sql语法，在PG上创建外表，同时创建外部服务器，存取巨杉中的数据，近期也支持了MySQL，将巨杉作为可插拔的存储引擎嵌入到MySQL中。

④目前巨杉用作交易类场景其实不多，现在最大的一个应用案例是某大行一百多物理节点的巨杉集群，用作数据归档和影像管理。

⑤巨杉底层是多模存储引擎，既支持结构化数据，也支持非结构化数据，实现了统一管理。

当然还有很多分布式数据库，像达梦、人大金仓、南大通用、万里开源、中兴等企业都有分布式数据库产品，这里不再一一介绍了。

作者介绍：

张小海，就职于某大型商业银行，目前主要负责数据库管理及新技术研究，PostgreSQL技术推广者，个人公众号：数据库架构之美。