突破关系型数据库桎梏：云原生数据库中间件核心剖析

作者介绍

张亮，京东数科数据研发负责人。热爱开源，目前主导两个开源项目Elastic-Job和Sharding-Sphere(Sharding-JDBC)。擅长以Java为主分布式架构以及以Kubernetes和Mesos为主的云平台方向，推崇优雅代码，对如何写出具有展现力的代码有较多研究。2018年初加入京东数科，现担任数据研发负责人。目前主要精力投入在将Sharding-Sphere打造为业界一流的金融级数据解决方案之上。

数据库技术的发展与变革方兴未艾，NewSQL的出现，只是将各种所需技术组合在一起，而这些技术组合在一起所实现的核心功能，推动着云原生数据库的发展。在上一篇文章《​​​关系型数据库尚能饭否？NoSQL、NewSQL谁能接棒？​​》中我们已经了解了云原生数据库的发展背景，所以本文会有针对性地深入解读云原生数据库的相关内容。

NewSQL的三种分类中，新架构和云数据库涉及了太多与数据库相关的底层实现，为了保证本文的范围不至太过发散，我们重点介绍透明化分片数据库中间件的核心功能与实现原理，另外两种类型的NewSQL在核心功能上类似，但实现原理会有所差别。

一、数据分片

传统的将数据集中存储至单一数据节点的解决方案，在性能和可用性两方面已经难于满足互联网的海量数据场景。由于关系型数据库大多采用B+树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的IO次数增加，进而导致查询性能的大幅下降；同时高并发访问请求也使得集中式数据库成为系统的最大瓶颈。

在传统关系型数据库无法满足互联网场景需要的情况下，将数据存储至原生支持分布式的NoSQL的尝试越来越多。但NoSQL对SQL的不兼容性以及生态圈的不完善，使得它们在与关系型数据库的博弈中始终无法完成致命一击，关系型数据库的地位依然不可撼动。

数据分片，指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中，以达到提升性能瓶颈及可用性的效果。数据分片的有效手段是对关系型数据库进行分库或分表。分库和分表均可以有效避免因为数据量超过可承受阈值而产生的查询瓶颈。

除此之外，分库还能够用于有效分散对数据库单点的访问量；而分表则能够提供尽量将分布式事务转化为本地事务的可能。使用多主多从的分片方式，可以有效避免数据单点，从而提升数据架构的可用性。

1、垂直分片

垂直分片又称为纵向拆分，它的核心理念是专库专用。在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则按照业务将表进行归类，分布到不同的数据库中，从而将压力分担到不同的数据库之上，如图：

2、水平分片

水平分片又称为横向拆分。相对于垂直分片，水平分片不是将数据根据业务逻辑分类，而是按照某个字段的某种规则将数据分散到多个库或表中，每个分片仅包含其中的一部分数据。

例如，根据ID的最后一位以10取余，尾数是0的放入0库（表），尾数是1的放入1库（表）。如图：

为了解决关系型数据库面对海量数据时因数据量过大而导致的性能问题，将数据进行分片是行之有效的解决方案。

将集中于单一节点的数据拆分并分别存储到多个数据库或表，称为分库分表。分库可以有效分散由高并发所带来的对数据库访问的压力。分表虽然无法缓解数据库压力，但仅跨分表的更新操作，依然能使用数据库原生的ACID事务；而一旦涉及到跨库的更新操作，分布式事务的问题就会变得无比复杂。

通过分库和分表拆分数据使得各个表的数据量保持在阈值以下。垂直分片往往需要对架构和设计进行调整，通常来讲，是来不及应对互联网快速变化的业务需求的，而且它也无法真正解决单点瓶颈。而水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。

分库和读写分离疏导流量是应对高访问量的常见手段。分表虽然可以解决海量数据导致的性能问题，但无法解决过多请求访问同一数据库导致的响应变慢问题。所以水平分片通常采取分库的方式，一并解决数据量和访问量巨大的问题。读写分离是另一个疏导流量的办法，但读写数据间的延迟是架构设计时需要考虑的问题。

虽然分库可以解决上述问题，但分布式架构在获得了收益的同时，也带来了新的问题。面对如此散乱的分库分表之后的数据，应用开发和运维人员对数据库的操作变得异常繁重就是其中的重要挑战之一。他们需要知道什么样的数据需要从哪个具体的数据库的分表中去获取。

新架构的NewSQL与数据分片中间件在这个功能的处理方式上是不同的：

• 新架构的NewSQL会重新设计数据库存储引擎，将同一表中的数据存储在分布式文件系统中。
• 数据分片中间件则是尽量透明化分库分表所带来的影响，让使用方尽量像使用一个数据库一样使用水平分片之后的数据库。

跨库事务是分布式数据库要面对的棘手事情。合理采用分表，可以在降低单表数据量的情况下，尽量使用本地事务，善于使用同库不同表可有效避免分布式事务带来的麻烦。在不能避免跨库事务的场景，有些业务仍需保持事务的一致性。而基于XA的分布式事务由于性能低下，无法被互联网公司所采纳，大多采用最终一致性的柔性事务代替分布式事务。

3、读写分离

面对日益增加的系统访问量，数据库的吞吐量面临着巨大瓶颈。对于同一时间有大量并发读操作和较少写操作类型的应用系统来说，将单一的数据库拆分为主库和从库，主库负责处理事务性的增删改操作，从库负责处理查询操作，能够有效的避免由数据更新导致的行锁，使得整个系统的查询性能得到极大改善。

通过一主多从的配置方式，可以将查询请求均匀分散到多个数据副本，能够进一步提升系统的处理能力。

使用多主多从的方式，不但能够提升系统的吞吐量，还能够提升系统的可用性，可以达到在任何一个数据库宕机，甚至磁盘物理损坏的情况下仍然不影响系统的正常运行。

读写分离本质上是数据分片的一种。与将数据根据分片键打散至各个数据节点的水平分片不同，读写分离则是根据SQL语义的分析，将读和写请求分别路由至主库与从库。读写分离的数据节点中的数据是一致的，而水平分片每个数据节点的数据内容却并不相同。将水平分片和读写分离联合使用，能够更加有效的提升系统性能，但同时也让系统维护更复杂。

虽然读写分离可以提升系统的吞吐量和可用性，但同时也带来了数据不一致的问题，这包括多个主库之间的数据一致性及主库与从库之间的数据一致性问题。并且，读写分离也带来了与数据分片同样的问题，它也会使得应用开发和运维人员对数据库的操作和运维变得更加复杂。

透明化读写分离所带来的影响，让使用方尽量像使用一个数据库一样使用主从数据库，是读写分离的主要功能。

4、核心流程

数据分片核心是由SQL解析、SQL路由、SQL改写、SQL执行及结果归并的流程组成。为了保持原有的应用程序实现低接入成本，则需兼容对数据库的访问，因此需要进行数据库协议的适配。

协议适配

NewSQL对传统关系型数据库的兼容性，除了SQL之外，兼容数据库的协议可以降低使用方的接入成本。开源的关系型数据库均能通过实现它的协议标准，将自己的产品装扮成原生的关系型数据库。

由于MySQL和PostgreSQL流行度较高，很多NewSQL会实现它们的传输协议，让使用MySQL和PostgreSQL的用户能够无需修改业务代码就自动接入NewSQL产品。

MySQL协议

MySQL是当前最为流行的开源数据库。要了解它的协议，可以通过MySQL的基本数据类型、协议包结构、连接阶段和命令阶段这4方面入手。

基本数据类型

MySQL协议包中所有的内容均由MySQL所定义的基本数据类型组成，具体数据类型参见下表：

MySQL基本数据类型

在需要将二进制数据转换为MySQL可理解的数据时，MySQL协议包将根据数据类型预先定义的位数读取，并转换为相应的数字或字符串；反之亦然，MySQL会将每个字段按照规范中规定的长度写入协议包。

协议包结构

MySQL协议由一个或多个MySQL协议包（MySQL Packet）组成。无论类型如何，它均由消息长度（Payload Length）、序列主键（Sequence ID）和消息体（Payload）这3部分组成：

• 消息长度为int<3>类型。它表示随后的消息体所占用的字节总数。需要注意的是，消息长度并不包含序列主键的占位在内。
• 序列主键为int<1>类型。它表示一次请求后返回的多个MySQL协议包中，每个协议包的序号。占位为1字节的序列主键最大值为0xff，即十进制的255，但这并非表示每次请求最多只能包含255个MySQL协议包，超过255的序列主键将再次从0开始计数。例如一次查询可能返回几十万的记录，那么MySQL协议包只需保证其序列主键连续，将大于255的序列主键重置为0，重新开始计数即可。
• 消息体的长度为消息长度所声明的字节数。它是MySQL协议包中真正的业务数据，根据不同的协议包类型，消息体的内容也不同。

连接阶段

连接阶段用于创建MySQL的客户端与服务端的通信管道。该阶段主要执行交换并匹配MySQL客户端与服务端的版本功能描述（Capability Negotiation）、创建SSL通信管道及验证授权这3个任务。下图以MySQL服务端为视角绘制了连接创建流程图：

MySQL连接阶段流程图

该图并未包含MySQL服务端与客户端的交互。实际上，MySQL的连接创建是由客户端发起的。

MySQL服务端在接收到客户端的连接请求后，先进行服务端和客户端版本间所具有的功能信息的交换和匹配（Capability Negotiation），然后根据两端的协商结果生成不同格式的初始化握手协议包，并向客户端写入改协议包。协议包中包括由MySQL服务端分配的连接主键、服务端当前版本功能描述（Capabilities）以及为验证授权生成的密文。

MySQL客户端在接收到服务端发送的握手协议包后，将发送握手协议响应包。该协议包中主要包含的信息是用于数据库访问的用户名及加密后的密码密文。

MySQL服务端接收到握手协议响应包之后，即进行授权校验，并将校验结果返回至客户端。

命令阶段

连接阶段成功之后，则进入命令执行的交互阶段。MySQL一共有32个命令协议包，具体类型参见下图：

MySQL命令包

MySQL的命令协议包分为4个大类，分别是：文本协议、二进制协议、存储过程及数据复制协议。

协议包消息体中的首位用于标识命令类型。协议包根据名称即可望文生义，在这里无需一一解释它们的具体用途，下文会解析几个重点的MySQL命令协议包：

• COM_QUERY

COM_QUERY是MySQL用于以明文格式查询的重要命令，它对应JDBC中的java.sql.Statement。COM_QUERY命令本身较为简单，它由标识符和SQL组成：

1              [03] COM_QUERY

string[EOF]    the query the server shall execute

COM_QUERY的响应协议包则较为复杂，见下图：

MySQL查询命令流程图

COM_QUERY根据其场景有可能返回4种类型，它们是：查询结果、更新结果、文件执行结果及错误结果。

当执行过程中出现如网络断开、SQL语法不正确等错误时，MySQL协议要求将协议包首位设置为0xff，并将错误信息封装至ErrPacket协议包返回。

通过文件执行COM_QUERY的情况并不常见，此处不再过多说明。

对于更新请求，MySQL协议要求将协议包首位设置为0x00，并返回OkPacket协议包。OkPacket协议包需要包含本次更新操作所影响的行记录数及最后插入的主键值信息。

查询请求最为复杂，它需要将读取int<lenenc>的方式获得结果集字段的数目创建为独立的FIELD_COUNT协议包返回。然后再依次将返回字段的每一列详细信息分别生成独立的COLUMN_DEFINITION协议包，查询字段的元数据信息最终以一个EofPacket结束。之后便可以开始逐行生成数据协议包Text Protocol Resultset Row，它本身并不关注数据的具体类型，会统一将其转换为string<lenenc>格式。数据协议包最终依然以一个EofPacket结束。

对应于JDBC中java.sql.PreparedStatement的操作，则是由MySQL协议包中的二进制协议组成，它们由COM_STMT_PREPARE、COM_STMT_EXECUTE、COM_STMT_ CLOSE、COM_STMT_RESET和COM_ STMT_SEND_LONG_DATA这5个协议包组成。其中最为重要的是COM_STMT_PREPARE和COM_STMT_ EXECUTE，它们分别对应JDBC中的connection.prepareStatement()方法以及connection.execute()&connection.executeQuery()&connection.executeUpdate()方法。

• COM_STMT_PREPARE

COM_STMT_PREPARE协议包与COM_QUERY协议包类似，同样是由命令标识符和SQL组成：

1              [16] COM_STMT_PREPARE

string[EOF]    the query to prepare

COM_STMT_PREPARE协议包的返回值并非查询结果，而是由statement_id、列数目和参数数目等信息组成的响应协议包。statement_id是由MySQL分配给完成预编译之后的SQL的唯一标识，通过statement_id即可从MySQL中获取相应的SQL。

由COM_STMT_PREPARE命令注册过的SQL，只需将statement_id传给COM_STMT_EXECUTE命令即可，无需将SQL本身再次传入，节省了无谓的网络带宽消耗。

而且MySQL可以根据COM_STMT_PREPARE传入的SQL预编译为抽象语法树以供复用，进而提升SQL的执行效率。采用COM_QUERY的方式执行SQL，则需要将每条SQL重新编译。这也是PreparedStatement比Statement效率更佳的原因所在。

• COM_STMT_EXECUTE

COM_STMT_EXECUTE协议包主要由statement-id和与SQL的配对的参数组成。它使用了一个名为NULL-bitmap的数据结构，用于标识参数中的空值。

COM_STMT_EXECUTE命令的响应协议包与COM_QUERY命令的响应协议包类似，都是采用字段元数据和查询结果集的格式返回，中间依然使用EofPacket间隔。

有所不同的是，COM_STMT_EXECUTE命令的响应协议包使用Binary Protocol Resultset Row来代替Text Protocol Resultset Row，它不会无视数据的类型统一转换为字符串，而是根据返回数据的类型，写入相应的MySQL基本数据类型，进一步节省网络传输的带宽。

其他协议

除了MySQL协议，PostgreSQL协议和SQLServer协议也是完全开源的，可以通过同样的方式实现。而另一个常用的数据库Oracle协议并不开源，无法通过这种方式实现。

SQL解析

相对于其他编程语言，SQL是比较简单的。不过，它依然是一门完善的编程语言，因此解析SQL语法与解析其他编程语言（如：Java语言、C语言、Go语言等）并无本质区别。

解析过程分为词法解析和语法解析。先通过词法解析将SQL拆分为一个个不可再分的单词。再使用语法解析器将SQL转换为抽象语法树。最后通过访问抽象语法树，提炼出解析上下文。

解析上下文包括表、选择项、排序项、分组项、聚合函数、分页信息、查询条件。如果是分片中间件类型的NewSQL还需要记录可能修改的占位符标记。

将SQL：select username, ismale from userinfo where age > 20 and level > 5 and 1 = 1解析为抽象语法树：

抽象语法树

生成抽象语法树的第三方工具有很多，ANTLR是不错的选择。它可以通过开发者定义的规则生成抽象语法树的Java代码并提供访问者接口。相比于代码生成，手写抽象语法树在执行效率方面会更加高效，但是工作量也比较大。对性能要求高的场景中，可以考虑定制化抽象语法树。

请求路由

根据解析上下文匹配数据分片策略，并生成路由路径。对于携带分片键的SQL路由，根据分片键的不同可以划分为单片路由(分片操作符是等号)、多片路由(分片操作符是IN)和范围路由(分片操作符是BETWEEN)。不携带分片键的SQL则采用广播路由。

分片策略通常可由数据库内置或由用户方配置。数据库内置的方案较为简单，内置的分片策略大致可分为尾数取模、哈希、范围、标签、时间等；由用户方配置的分片策略则更加灵活，可以根据使用方需求定制复合分片策略。

SQL改写

新架构的NewSQL无需SQL改写，这部分主要是针对分片中间件类型的NewSQL。它用于将SQL改写为在真实数据库中可以正确执行的语句。包括将逻辑表名称替换为真实表名称，将分页信息的起始取值和结束取值改写，增加为排序、分组和自增主键使用的补列，将AVG改写为SUM/COUNT等。

结果归并

将多个执行结果集归并并统一对应用端输出。结果归并包括流式归并和内存归并：

• 流式归并用于简单查询、排序查询、分组查询及排序和分组但排序项和分组项完全一致的场景，流式归并结果集的遍历方式是通过每一次调用next方法取出，无需占用额外的内存。
• 内存归并则需要将结果集中所有数据加载至内存处理，如果结果集数据过多，会占用大量内存。

二、分布式事务

前文提到过，数据库事务是需要满足ACID（原子性、一致性、隔离性、持久性）这四个特性的：

• 原子性（Atomicity）指事务作为整体来执行，要么全部执行，要么全不执行。
• 一致性（Consistency）指事务应确保数据从一个一致的状态转变为另一个一致的状态。
• 隔离性（Isolation）指多个事务并发执行时，一个事务的执行不应影响其他事务的执行。
• 持久性（Durability）指已提交的事务修改数据会被持久保存。

在单一数据节点中，事务仅限于对单一数据库资源的访问控制，称之为本地事务。但在基于SOA的分布式应用环境下，越来越多的应用要求对多个数据库资源、多个服务的访问都能纳入到同一个事务当中，分布式事务应运而生。

关系型数据库虽然对本地事务提供了完美的ACID原生支持。但在分布式的场景下，它却成为系统性能的桎梏。如何让数据库在分布式场景下满足ACID的特性或找寻相应的替代方案，是分布式事务的重点工作。

1、XA协议

最早的分布式事务模型是由X/Open国际联盟提出的X/Open Distributed Transaction Processing（DTP）模型，简称XA协议。

DTP模型中通过一个全局事务管理器与多个资源管理器进行交互。全局事务管理器负责管理全局事务状态和参与事务的资源，资源管理器则负责具体的资源操作，DTP模型与应用程序的关系见下图：

DTP模型

XA协议使用两阶段提交来保证分布式事务原子性。它将提交过程分为准备阶段和提交阶段。

• 在准备阶段时，全局事务管理器向每个资源管理器发送准备消息，用于确认本地事务操作的成功与否；
• 在提交阶段时，若全局事务管理器收到了所有资源管理器回复的成功消息，则向每个资源管理器发送提交消息，否则发送回滚消息。资源管理器根据接收到的消息对本地事务进行提交或回滚操作。

下图展示了XA协议的事务流程：

XA事务流程

二阶段提交是XA协议的标准实现。它将分布式事务的提交拆分为两阶段：prepare和commit/rollback。

开启XA全局事务后，所有子事务会按照本地默认的隔离级别锁定资源，并记录undo和redo日志，然后由TM发起prepare投票，询问所有的子事务是否可以进行提交：当所有子事务反馈的结果为“yes”时，TM再发起commit；若其中任何一个子事务反馈的结果为“no”，TM则发起rollback；如果在prepare阶段的反馈结果为yes，而commit的过程中出现宕机等异常时，则在节点服务重启后，可根据XA recover再次进行commit补偿，以保证数据的一致性。

基于XA协议实现的分布式事务对业务侵入很小，它最大优势就是对使用方透明，用户可以像使用本地事务一样使用基于XA协议的分布式事务。XA协议能够严格保障事务ACID特性。

但严格保障事务ACID特性是一把双刃剑。

事务执行在过程中需要将所需资源全部锁定，它更加适用于执行时间确定的短事务，对于长事务来说，整个事务进行期间对数据的独占，将导致对热点数据依赖的业务系统并发性能衰退明显。因此，在高并发的性能至上场景中，基于XA协议的分布式事务并不是最佳选择。

2、柔性事务

如果将实现了ACID事务要素的事务称为刚性事务的话，那么基于BASE事务要素的事务则称为柔性事务。BASE是基本可用（Basically Available）、柔性状态（Soft state）和最终一致性（Eventually consistent）这三个要素的缩写：

• 基本可用保证分布式事务参与方不一定同时在线；
• 柔性状态允许系统状态更新有一定的延时，这个延时对客户来说不一定能够察觉；
• 最终一致性通常是通过消息可达的方式保证系统的最终一致性。

在ACID事务中对隔离性的要求很高，在事务执行过程中，必须将所有的资源锁定。柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性要求，来换取系统吞吐量的提升。

由于在分布式系统中，可能会出现超时重试的情况，因此柔性事务中的操作必须是幂等的，需要通过幂等来避免多次请求所带来的问题。实现柔性事务的方案主要有最大努力送达、Saga和TCC。

最大努力送达

是最简单的一种柔性事务，它适合对于数据库的操作最终一定能够成功的场景。由NewSQL自动记录执行失败的SQL，并反复尝试，直至执行成功。使用最大努力送达型的柔性事务是没有回滚功能的。

这种类型的柔性事务实现最为简单，但是对场景的要求十分苛刻。这种策略的优点是无锁定资源时间，性能损耗小。缺点是尝试多次提交失败后，无法回滚，它仅适用于事务最终一定能够成功的业务场景。因此它是通过事务回滚功能上的妥协，来换取性能的提升。

Saga

Saga源于1987年由Hector Garcaa-Molrna和Kenneth Salem发表的论文。

论文参考链接：

www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf

Saga事务更适合使用长事务的场景。它由多个本地事务所组成，每个本地事务有相应的执行模块和补偿模块，任何一个本地事务出错时，可以通过调用相关的补充方法达到事务的最终一致性。

Saga模型将一个分布式事务拆分为多个本地事务，每个本地事务都有相应的执行模块（Transaction）和补偿模块（Compensation）。当Saga事务中的任一本地事务执行失败时，可以通过调用其相关补偿方法恢复之前的事务，以达到事务最终的一致性。

当每个Saga子事务T1,T2,…,Tn都有对应的补偿定义C1,C2,…,Cn-1，那么Saga系统可以保证：

• 子事务序列T1,T2,…,Tn得以完成 。这是事务的最佳情况，即无需回滚的情况。
• 或者序列T1,T2,…,Tx, Cx,…,C2,C1,（其中x小于n）得以完成。它能够保证当回滚发生时，补偿操作按照正向操作相反的顺序依次执行。

Saga模型同时支持正向恢复以及逆向恢复。正向恢复是指重试当前失败的事务，它的实现前提是每个子事务都能够最终执行成功；向后恢复则是前文提及的，在任一子事务失败时，补偿所有已完成的事务。

显然，正向恢复没有必要提供补偿事务，如果在业务中的子事务最终总会成功，那么向前恢复则能够降低Saga模型的使用复杂度。另外，如果补偿事务难以实现，则正向恢复也是不错的选择。

虽然在理论上来讲，补偿事务永不失败。然而，在分布式的世界中，服务器可能会宕机、网络可能会失败，甚至数据中心也可能会停电。因此，需要提供故障恢复后回退的机制，比如人工干预。

Saga模型没有XA协议中的准备阶段，因此事务没有实现隔离性。如果两个Saga事务同时操作同一资源则会产生更新丢失，脏数据读取等问题。这就需要使用Saga事务的应用程序需要在应用层面加入资源锁定的逻辑。

TCC

TCC（Try-Confirm-Cancel）分布式事务模型通过对业务逻辑的分解来实现分布式事务。顾名思义，TCC事务模型需要业务系统提供以下三段业务逻辑：

• Try。完成业务检查，预留业务所需资源。Try操作是整个TCC的精髓所在，可灵活选择业务资源锁的粒度。
• Confirm。执行业务逻辑，直接使用Try阶段预留的业务资源，无需再次做业务检查。
• Cancel。释放Try阶段预留的业务资源。

TCC模型仅提供两阶段原子提交协议，保证分布式事务原子性。事务的隔离交给业务逻辑来实现。TCC模型的隔离性思想就是通过业务的改造，从数据库资源层面加锁上移至业务层面加锁，从而释放底层数据库锁资源，放宽分布式事务锁协议，提高系统的并发性。

虽然在柔性事务中，TCC事务模型的功能最强，但需要应用方负责提供实现Try、Confirm和Cancel操作的三个接口，供事务管理器调用。因此业务方改造的成本较高。

以A账户向B账户汇款100元为例，下图展示了TCC对业务的改造：

汇款服务和收款服务分别需要实现，Try-Confirm-Cancel接口，并在业务初始化阶段将其注入到TCC事务管理器中。

汇款服务

Try

• 检查A账户有效性，即查看A账户的状态是否为“转帐中”或者“冻结”；
• 检查A账户余额是否充足；
• 从A账户中扣减100元，并将状态置为“转账中”；
• 预留扣减资源，将从A往B账户转账100元这个事件存入消息或者日志中。

Confirm

• 不做任何操作。

Cancel

• A账户增加100元；
• 从日志或者消息中，释放扣减资源。

收款服务

Try

• 检查B账户账户是否有效。

Confirm

• 读取日志或者消息，B账户增加100元；
• 从日志或者消息中，释放扣减资源。

Cancel

• 不做任何操作。

由此可以看出，TCC模型对业务的侵入较强，改造的难度较大。

消息驱动

消息一致性方案是通过消息中间件保证上下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个本地事务中，下游应用向消息系统订阅该消息，收到消息后执行相应操作。本质上是依靠消息的重试机制，达到最终一致性。下图是消息驱动的事务模型：

消息驱动的缺点是：耦合度高，需要在业务系统中引入消息中间件，导致系统复杂度增加。

总的来说，基于ACID的强一致性事务和基于BASE的最终一致性事务都不是银弹，只有在最适合的场景中才能发挥它们的最大长处。详细对比一下它们之前的区别，以帮助开发者进行技术选型。由于消息驱动与业务系统的耦合度较高，因此不列入对比表格：

一味的追求强一致性未必是最合理的解决方案。对于分布式系统来说，建议使用“外柔内刚”的设计方案。外柔指的是在跨数据分片的情况下使用柔性事务，保证数据最终一致即可，并且换取最佳性能；内刚则是指在同一数据分片内使用本地事务，以达到ACID的效果。

三、数据库治理

1、基础治理

前文讲述的服务治理，在数据库的基础治理部分大都是通用的。主要包括配置中心、注册中心、限流、熔断、失效转移、调用链路追踪等：

• 配置中心用于配置集中化以及动态配置更新及通知下发；
• 注册中心用于服务发现，这里的服务是指数据库中间层实例本身，通过它可以实现状态监测及自动通知，进而使得数据库中间件具备高可用和自我治愈能力；
• 限流用于流量的过载保护，分为数据库中间件本身的流量过载保护和对数据库的流量过载保护；
• 熔断也是流量过载的保护措施之一，它的不同之处在于熔断整个客户端对数据库的访问，以保护数据库能够为其他流量正常的系统继续提供服务，可以通过前文讲的熔断器模式实现自动熔断机制；
• 失效转移用于多数据副本的情况，在数据完全一致的多数据节点中，当某一节点不可用后，可通过失效转移的机制让数据库中间件访问至另外有效的数据节点操作数据；
• 调用链路追踪则是将对数据库访问的调用链路、性能、拓扑关系等指标以可视化的方式展现出来。

2、弹性伸缩

数据库治理与服务治理不同的关键点在于，数据库是有状态的，每个数据节点都有自己持久化的数据，因此很难像服务化一样做到弹性伸缩。

当系统的访问量和数据量超过之前评估的预期时，往往涉及到对数据库的重新分片。虽然使用日期分片等策略时，可以在无需迁移遗留数据的情况下直接扩容，但在大部分场景中，数据库中的遗留数据往往无法直接映射到新的分片策略中。分片策略的修改则需要进行数据的迁移。

在传统的系统中，停止服务进行数据迁移，迁移结束之后再重启服务是行之有效的解决方案。但这种方案使得业务方的数据迁移成本非常高，需要业务方工程师精准的评估数据量。

在互联网场景中，系统可用性要求极高，而且业务爆发性增长的可能性较传统行业也更加常见。在云原生的服务架构模型中，弹性伸缩是常见的需求，并且可以比较轻松的实现。因此与服务对等的数据弹性伸缩功能，是云原生数据库的重要能力。

除了系统预分片之外，弹性伸缩的另一个实现方案是在线数据迁移。在线数据迁移经常被比喻为“在飞行过程中给飞机换引擎”，它最大的挑战是如何保证迁移过程使服务不受影响。在线数据迁移可以在修改了数据库的分片策略之后（比如将根据主键%4分为4个库的分片方式改为根据主键%16的16个库的分片方式），通过一系列的系统化操作，保证数据正确的迁移到新的数据节点的同时，让依赖数据库的服务完全无需感知。它可以分为以下4个步骤：

• 同步线上双写。即同时将数据写入分片策略修改前的原数据节点及分片策略修改后的新数据节点。可以通过一致性算法来保证双写的一致性，如前文介绍过的Paxos或Raft算法；
• 历史数据迁移。以离线的方式，将需要迁移到新数据节点部分的历史存量数据从原有数据节点迁移过去。可以通过SQL的方式，也可以通过binlog等二进制方式进行处理；
• 数据源切换。将读写请求切换至新的数据源，并停止对原数据节点的双写；
• 清理冗余数据。在旧数据节点中，清理已迁移至新数据节点的相关数据。

在线数据迁移不仅可以做数据扩容，也可以通过同样的方式在线进行DDL操作。由于数据库原生的DDL操作是不支持事务的，而且在对包含大量数据表做DDL时会导致长时间锁表，因此，通过在线数据迁移的方式，是能够支持在线DDL操作的。在线DDL操作与数据迁移步骤是一致的，只需要在迁移之前新建一个DDL修改后的空表，然后根据上述4步骤进行即可。

Sharding-Sphere近期相关计划安排是什么呢？欢迎大家来github围观、留言！

​​https://github.com/sharding-sphere/sharding-sphere/issues/1189​​

Sharding-Sphere自2016开源以来，不断精进、不断发展，被越来越多的企业和个人认可：在Github上收获5000+的star，2000+forks，60+公司企业的成功案例。此外，越来越多的企业和个人也加入到Sharding-Sphere的开源项目中，为它的成长和发展贡献了巨大力量。

我们从未停息过脚步，聆听社区伙伴的需求和建议，不断开发新的、强大的功能，不断使其健壮可靠！

开源不易, 我们却愿向着最终的目标，步履不停！

那么，正在阅读的你，是否可以助我们一臂之力呢？分享、转发、使用、交流，以及加入我们，都是对我们最大的鼓励！

项目地址：

​​https://github.com/sharding-sphere/sharding-sphere/​​

更多信息请浏览官网：

​​http://shardingsphere.io/​​