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

一、数据分片

传统的将数据集中存储至单一数据节点的解决方案，在性能和可用性两方面已经难于满足互联网的海量数据场景。由于关系型数据库大多采用 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_QUERYstring[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_PREPAREstring[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 模型与应用程序的关系见下图：

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 步骤进行即可。

企业 IT 预算不高，但又有业务硬需求，怎么办？即日起至 3 月 31 日，京东云“开年嗨购季”云主机、云数据库、云存储、云硬盘、云安全等多类爆款产品低至 1.4 折起！还有京鱼座 C1 智能音箱、京鱼座 I8 智能音箱、iPhone 12 64G 手机等豪礼相送！点击【阅读原文】，查看活动详情。

推荐阅读

• 上云三问 | 京东云这次的大促有哪些“不一样”？
  

• 亿级数据库毫秒级查询？看完这一篇，海量数据赋能你也行
  

• 比MySQL快839倍！揭开分析型数据库JCHDB的神秘面纱
  

欢迎点击【京东科技】，了解开发者社区

更多精彩技术实践与独家干货解析

欢迎关注【京东科技开发者】公众号