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

数据库技术的发展与变革方兴未艾，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的配对的参数组成。它使用了一个名为-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发表的论文。

论文