一. 背景

在各个行业，随着业务迅猛发展，很多系统都会面临处理高并发、大数据量、超高峰值等多种场景。以金融行业为例，由于互联网的普及，很多互联网业务得到迅猛发展，于是业务系统对应的活跃用户量和数据量也会出现迅猛增长，比如各种场景的在线支付（水费、电费、电话费等各种高频次的小额消费）、网上银行、手机银行等；还有一类场景是具有极高峰值的业务系统，比如 6.18 、双十一、纪念币预约、抢购、秒杀、春节红包、春节火车票等。

传统单机数据库的处理能力已经难以支撑这些业务发展，于是，开始探索各种解决各种有效的方案，最常见的就是应用系统通过分库分表进行解决。但是，这种解决方案一方面应用系统需要做大量改造，需要感知数据存储位置，一方面增加了运维的复杂性。于是出现了中间件的方式，如 mycat 等。这种方式实现了数据对应用的透明，但未解决数据库运维的痛点。

近年来，互联网、银行业等各行业对处理这类问题逐渐探索形成了自己的思路和解决方案，进一步出现了分布式数据库产品。它们的设计理念和技术路线各不相同，却需要解决一些成熟的分布式数据库产品必然会面临的技术问题。这些问题或者与选择的技术路线有关，或者是做分布式数据库产品必然面临的问题，它们的解决方案和实现机制各不相同，但它们也存在一些共性。因此，本文拟通过对业界分布式数据库产品的研究和探索，介绍一些常见功能的主流方案和技术趋势，以此抛砖引玉，以飨读者。

二. 技术路线

目前业界的分布式数据库产品非常多，各有优缺点，本文不会成为某种产品的推荐者或者批判者。按照目前业界现状，技术路线分类如下：

基于开源数据库 + 中间件：开源单机数据库（如 mysql 、 postgres 等）已经经过了几十年的应用，产品功能相对稳定，单机数据处理性能也相对比较高。这种方案的优点是可以利用现有单机数据库稳定的产品功能，缺点是中间件的功能实现要受限于单机数据库的功能。比如，中间件要实现一个对数据表列进行加密的功能，如果单机数据库不具备这种功能，中间件只能采用迂回折中的方式。当然，也有足够研究能力的厂商会对单机数据库进行功能优化和改进，比如 mysql 的主从同步机制、热点数据访问等，这对厂商的研发能力和技能储备要求非常高。

完全自研：公司组建团队进行产品的自研开发，当然，不可能完全重复造轮子，在实现部分产品功能时可能会采用或者借鉴一些开源软件，比如 TiDB 的数据存储使用了 RocksDB 。数据资产是公司最核心的资源，尤其是银行等金融行业，数据库不能出现重大问题，但数据库的产品功能完善需要经过一段时期的生成环境验证，需要填各种坑。因此，这种方案的优点是天生具有分布式的特性，从设计之初就是针对分布式架构进行设计的，而单机数据库的很多设计当时还未具备分布式的思维理念，缺点是产品的功能需要经过不同场景、不同数据量和不同行业用户的检验、改进和完善，才能具备成熟度，需要团队具备相应的应用场景。自研的数据库产品，有些是采用开源模式，比如 TiDB ，有些是闭源模式，比如 OceanBase 从 1.0 版本 1.0 起已经闭源，网上有些错误的文章都是针对之前它们的开源版本 0.4 进行的研究和讨论。

三. 关键技术

目前数据库产品的业务场景一般分为支持 OLTP 、 OLAP 和 HTAP （ Hybrid Transactional/Analytical Processing ） 。目前 OLAP 已经有很多成熟的产品或者大数据开源软件支持， HTAP 的理念是用一款产品同时解决 OLAP 和 OLTP 的场景。笔者以为，专业的场景需要专业的软件，没有万能的“银弹”， HTAP 中的 OLAP 一般适用于数据不是特别大的情况，真正海量数据还需要专业 OLAP 解决方案。因此，本节分析主要基于对 OLTP 型数据库的分析。

分布式数据库一般由多个管理节点和数据节点组成，分别负责分布式数据库的运维和数据存储。相比于单机数据库，分布式数据库具有“逻辑统一、物理分散”的特点，逻辑统一是指，从用户角度看，不论多少个节点组成数据库的完整功能，对用户而言，都表现的像是一个单机数据库；物理分散是指，从实现角度看，分布式的数据库功能分别由不同的节点完成，由其内部进行自动化的统一调度。逻辑统一的要求和物理分散的实现，决定了在很多产品功能实现上，相较于单机数据库具有一定的复杂性和技术难度。

本文基于对市场多款数据库产品的分析和研究，将从语法兼容性、数据分布、分布式事务、读写分离、数据复制、数据备份恢复、容灾高可用七个方面，分别介绍各重要功能的业界发展趋势。

1.语法兼容性

逻辑统一的用户体验，决定了 SQL 语法需要兼容单机数据库。由于研发分布式数据库产品的公司多为互联网、创业公司等，它们一般都以使用 MySQL 为主，很少使用商业数据库 DB2 、 Oracle 等。其中， Sql 语法分为 DDL 和 DML 两类， DDL 一般又分为更删改查、聚合函数、存储过程等。因此，目前技术趋势如下：

1） 所有市场产品均声称兼容 MySQL ，有部分定位于对标 Oracle 的产品，也在逐步兼容 Oracle 语法。

2） 无法实现 MySQL 语法的完全相同。通常，在存储过程方面兼容性较差，甚至不兼容。那么，不兼容时会不会影响使用呢？不会。存储过程的本质就是很多 SQL 语句的聚合，减少客户端和服务端的交互成本，提升效率。当不兼容时，可以将存储过程的 SQL 交给应用程序处理，在很多银行同业的 SQL 规范中，不推荐或者禁止使用存储过程。绝大多数产品是兼容绝大多数 SQL 语法，真正意义的 100% 相同是难以做到的，即便做到，为了一些不常用的功能所付出的努力也需要产品设计者进行投入产出比的衡量。还有一些产品号称 100% 兼容 Oracle 语法， Oracle 语法十分复杂，这根本难以做到。

3） 产品具有自己的语法扩展。在实现 MySQL 语法兼容的同时，很多产品为了解决性能和功能的问题，经常会对语法进行扩展，这种特点语法具有产品烙印，不具备通用性。比如， MySQL 语法中新增类似 Oracle 的 hint 功能，用于指定本语句修改的数据所在的节点。对应用而言，这种改动量相对比较小，和 mysql 互相迁移的工作量不大。

4） 产品的 SQL 语法在不断完善和发展。特别是当产品在进行 POC 或者与产品客户以联合创新模式进行一些业界合作时，会不断增加新功能适应业务需求。

2.数据分布

单机的纵向扩展能力受主板卡槽等影响存在上限，有单机处理容量和速度的上限，而分布式数据库则是通过横向扩展能力来无限提升数据库处理速度、性能和容量。对于一个数据量很大的表，往往需要将其分布到多个节点进行处理。目前技术趋势如下：

1） 支持常见的数据分布方式有 hash 、 range 和 list 。 MySQL 的语法还有一种 key ，但是可以类似于 hash ，区别在于 key 的 hash 函数由服务器提供。当然，有部分产品只支持其中一种或者两种。在银行业，比如银行卡等部分业务数据还具有一个特征，就是某个字符串的中间部分是具有业务特征，比如可能是省市代码，如果可以支持对字符串的子串支持多种分布方式会简化应用开发，但目前几乎没有产品支持这个功能。

2） 单表复制。在对分布在多个数据节点的 2 个表进行表连接时，会涉及网络通讯和大量数据传输，会影响性能。比如， A 表和 B 表进行表连接， B 表进行 hash 后保存在四个节点，如果此时在四个节点上均保存一份全量数据 A ，那么可以分别在四个节点完成表连接，然后再进行数据汇总。这种场景成为单表复制。这种表一般是数据量相对较少，数据改动较小。数据量少，是需要单个数据节点可以对其进行处理，数据改动较小是为了降低数据频繁改动时的性能影响。因为每次修改数据，需要同步修改四个数据节点的数据。

3.分布式事务

分布式事务是分布式数据库的重点，也是它的难点。产品的实现方式各不相同，主要有如下两种流派：

1） 两阶段提交：这种业界最主流的选择方案，区别在于不同的产品对两阶段的实现方式不同，一种是利用 MySQL 支持的 XA 协议， MySQL 提供了 XA 协议的接口，可以在此基础上实现，一般用于采用中间件技术路线的产品；一种自己实现 XA 协议，一般用于自研路线的产品。目前这是业界实现主流。

2） 一阶段提交 + 事务补偿：这种方案设计者一般认为两阶段的成本较高，因此将分布式事务的各个阶段分别进行提交，如果某个阶段发生异常时，再对已提交的各阶段事务进行事务冲正。目前只有个别产品采用这种方案。

不论哪种流派，分布式事务的设计有两个难点：

1） 分布式事务的异常处理：从正常流程看，哪种方案都看似行得通，无法厚非。但真正设计难点在于分布式的参与节点多，在这个过程中，无论哪个节点都有可能故障，问题在于：无论哪个节点或者阶段发生过程，如何保证事务的完整性和数据一致性。

2） 分布式事务的隔离级别：如果对标单机数据库的四个事务隔离级别，分布式事务完全实现具有很高的难度，所有产品均实现难度不大的已提交读，部分产品实现了可串行化读，其它两个隔离级别实现起来复杂度较高。

3） 分布式事务的性能优化：由于分布式事务在 commit 阶段需要处理大量操作，甚至是跨节点的操作，因此，如何区分本地事务和分布式事务，如何优化提升分别式事务，是一个复杂的问题。由于每家产品各不相同，因为不具有通用可总结的规律。

4） 分布式事务的数据多版本控制（ MVCC ）： Oracle 和 MySQL 均实现了 MVCC 功能。但分布式事务的 MVCC 功能实现具有一定难度，如果结合事务隔离级别，实现难度更大。

因此，目前分布式数据库的分布式事务还为完全对标单机数据库的隔离级别，是在一个不断演进和优化的过程。

4.数据复制

不同于 DB2 、 Oracle 等数据库采用增强存储硬件可靠性，分布式数据库使用廉价 PC 服务器，它们的特点就是故障率相对比较高。对于一个数百台机器组成的分布式数据库时，出现几台服务器故障都是正常现象。分布式数据库一般采用 share nothing 的模型，每个数据节点都采用自己的本地存储。主要技术特点如下：

1） 为了保证数据的可靠性，必须将数据保存多份，经典的数值是三份： hadoop 中数据也是默认保存三份。这样，三个节点完全坏掉的可能性非常小，但并非理论上的不可能。对于一些数据安全性要求高的场景，可以保存五份。每多保存一份，就多一份的硬件支出成本，因此需要进行硬件成本和数据安全容忍度的平衡。

2） 为兼顾多个节点的数据安全性和数据写性能，一般采用超半数同步写成功的原则。在将数据保存三份或者五份时，在写数据时，如果只有一个节点写成功，其它节点采用异步模式，当该节点坏道，其它节点还未写成功时就会存在数据丢失的可能性；如果等待所有节点写成功，那么响应时间可能比较长，无法满足性能要求。因此，采用了折中方法，即超过半数同步写成功即可。这种思想可以采用 paxos 或者 raft 协议实现。

5.读写分离

在数据存在多份时，会有一个节点作为主节点，其余节点保持与它的同步，称为从节点。由于半数写成功原则的存储，尤其在数据节点比较繁忙的时候，存在部分从节点与主节点不一致的情况。如果所有客户端的请求均发给主节点，主节点要承担所有读写功能，在高负载的情况下会雪上加霜，造成响应速度很慢。在常用业务场景中，一般都是写少读多。因此，对于一些对数据实时性要求不高的业务场景，可以将客户端的读请求发给从节点，从而降低从节点的负载。比如，信用卡的刷卡消费，一般都是在第二天出账，当时刷完直接查看账单内容的相对较少。当然，一般主从之间的延迟不会按照小时算，一般都在数秒之内。

6.数据备份恢复

数据的备份恢复是数据库运维的基本操作。对于运维人员而言，一般是希望通过一个命令操作可以备份所有数据节点的数据，如同单机数据库备份一样。但是，因为备份过程需要每个节点的数据库单独进行备份，因此，需要保持每个数据节点的备份都是在同一个时间节点的备份快照，这非常重要。

业界常用的解决方法是在备份操作启动的时间，记录下整个数据库的当前最大事务 ID ，比如 LSN ，同时备份数据文件和日志文件。数据文件的备份可以采用物理备份，在备份的过程中可能会产生客户端请求修改数据的情况，这些修改的操作都已经通过日志文件进行了备份。在进行数据恢复时，首先还原数据文件，然后通过重复日志文件，一直到需要操作的时间点。

7.容灾高可用

传统单机数据库的高可用和异地容灾，比如 Oracle ，多采用 ADG 和 OGG 的模式进行数据实时同步，但是当主库发生故障时，切换到备库。在实时操作过程中，虽然可以进行自动切换，但为了检查主库和从库的一致性，银行业很多案例都需要进行人工核对，这样故障恢复就需要一定时间。但是分布式数据库的多数据副本模式就很好的解决了这个问题。比如三副本情况下，可以将 2 个节点放在本地机房，第三个节点放在异地机房。在正常情况下，进行数据修改时，按照超过半数即为成功的原则，由于本地的 2 个节点网络时延小，就会很开完成操作并相应客户端。当发生某个节点故障时，可以自动切换到本地节点的另外一个节点，同时第三个节点还在运行，只要这 2 个节点都写成功，仍然正常提供服务，此时业务系统相应时间过变长，可以视作服务能力降级，但是不会发生业务系统宕机。对于一些非常重要的系统，甚至可能采用 4+1 ，同城机房有 4 个节点，两个机房各有 2 个节点，第 5 个节点（即 4+1 中的 1 ）在异地机房，这样，即便本地机房节点故障发生 1 个节点故障，不会服务降级。

四. 现状分析

最近一两年的时间，分布式数据库产品蓬勃发展，在很多银行、保险等金融业得到不断的探索和试用，有一些甚至在生产系统中得到大量应用，但总体看，这个行业还有如下特点：

1） 产品功能迭代较快，主要体现在 SQL 语法和运维功能方面。由于大量的 POC 测试或者试用，银行业的金融级数据库服务要求又很严格苛刻，因此厂商可以收集大量需求，有利于增加新语法的兼容，还有增加运维的便利性；

2） 目前的产品试用主要在一些非核心业务。由于主机的特点和金融监管的要求，目前绝大部分案例都是在一些非核心系统的应用，有一些渠道类业务（比如网联、第三方支付对接等）应该开始在试用，在生产环境中验证产品功能和稳定性。中信银行正在尝试将核心运行在分布式数据库上面，但是目前也是采用双写模式，还没有时限真正的切换；

3） 产品的成熟度有待提升。相比较于 DB2 、 Oracle 等商业数据库和 MySQL 等开源数据库，产品在生态圈、技术手册、技术支持等多个方面，还是稍逊一等，仍然有大量可提升的空间。

4） 目前市场产品群雄逐鹿。目前，各家银行同业现状看，根据自己的实际情况不同，认识各不相同，也青睐于不同的产品或者解决方案。由于尚无统一的业界标准，现在也各有各看法，没有哪一款产品是这个领域不可争议的第一名，就如同 Oracle 一样。