本文转载于51CTO.com，作者：张小海
行业背景
随着全球经济下行压力增大，中美贸易摩擦愈演愈烈，美国一系列的经济制裁和技术封锁使得我们有种被扼住咽喉的感觉，数据库作为基础软件中的重要一环有着很深的技术含量，在这样的大背景下国产数据库厂商开始发力，这其中分布式数据库如雨后春笋般出现，良性的竞争环境使它们都得到了长足的发展，其中不乏优秀的产品，本文主要挑选目前几个相对成熟数据库进行架构特点介绍。
分布式数据库总体架构
分布式数据库总体设计有两个思路和方向，一个是基于共享存储的架构(share everything)，另一个是基于数据分片的架构(share nothing)。
共享存储的架构特点是底层存储共用一份数据池子，上层数据库server层可以弹性扩展，典型的案例像DB2 pureScale，Oracle RAC，阿里云PolarDB等，这种架构的好处是天然适合做云数据库，比如阿里云，上层的SQL引擎可以是MySQL也可以是PG，而且可以无限扩展，底层的存储其实是一起的，用户申请只是申请几个上层的MySQL或者PG server同时在底层存储开辟一块空间给用户，这样的话可以做到资源的弹性伸缩。这种架构的数据库严格意义上不能称之为分布式数据库。
数据分片架构的特点是底层数据通过一定的规则比如hash或者range让数据打散分别分布到不同的数据节点上，计算时底层多个节点共同参与计算，可以算是一种mpp并行计算的架构，同时数据节点可以扩展，上层由协调节点进行SQL解析和转发，这是目前典型的分布式数据库架构，也是本文讨论的重点。
目前分布式数据库的总体架构设计基本都和下图相差不大，每种产品在不同组件的实现上存在差异，但大体架构上类似。
从图中可以看到分布式数据库三大组件：协调节点、数据节点、全局事务管理器。协调节点负责SQL解析转发，充当的是类似proxy的角色，数据节点负责计算和数据存储，全局事务管理器负责全局事务读一致性的保证。
下面分别介绍一下目前主流的分布式数据库的架构以及设计差异。
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实现了逻辑上的时间戳，谷歌论文也提出了原子钟的概念，从物理上保证事务号全局有序。
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这些产品。
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。
SequoiaDB
SequoiaDB是巨杉自主研发的分布式数据库，最初的应用场景主要是历史数据归档和非结构化数据存档，但是近期来巨杉也在积极开发oltp功能，包括研发GTM，支持MySQL协议等。下面介绍一下它的架构特点：
①包括协调节点、编目节点、数据节点、PG节点等。协调节点负责sql转发，编目节点存储元数据，数据节点存储真实数据，PG节点做sql引擎。
②巨杉数据库底层存储是NoSQL的，数据都是JSON格式进行存储，优点类似MongoDB。
③PG节点是将PG Server拿过来做sql存储引擎，支持sql语法，在PG上创建外表，同时创建外部服务器，存取巨杉中的数据，近期也支持了MySQL，将巨杉作为可插拔的存储引擎嵌入到MySQL中。
④目前巨杉用作交易类场景其实不多，现在最大的一个应用案例是某大行一百多物理节点的巨杉集群，用作数据归档和影像管理。
⑤巨杉底层是多模存储引擎，既支持结构化数据，也支持非结构化数据，实现了统一管理。
当然还有很多分布式数据库，像达梦、人大金仓、南大通用、万里开源、中兴等企业都有分布式数据库产品，这里不再一一介绍了。
