京东数科强一致、高性能分布式事务中间件 JDTX

在分布式数据库、云原生数据库、NewSQL 等名词在数据库领域层出不穷的当今，变革——在这个相对稳定的领域已愈加不可避免。相比于完全革新，渐进式增强的方案在拥有厚重沉淀的行业则更受青睐。

同所有分布式领域的解决方案相同，分而治之的透明化数据分片方案，是新一代数据库解决海量数据的核心理念。水平拆分使得分布式事务的重要性，较之垂直拆分的业务系统进一步提升。另外，弹性扩（缩）容、HTAP 等概念也是新一代数据库的关注重点。京东数科开源的 Apache ShardingSphere 在数据分片方面已逐渐成熟，在此场景之上开发的分布式事务中间件 JDTX 与之共同组成了分布式数据库的内核拼图。

JDTX 是由京东数科的数据研发团队倾力打造的分布式事务中间件。本次分享是 JDTX 首次公开出现在大众视野面前，分享内容涵盖 JDTX 的核心设计理念及相关的技术实现难点，希望能为打造分布式事务解决方案的团队提供一些思路。

背景

数据库事务需要满足 ACID（原子性、一致性、隔离性、持久性）4 个特性。

在单一数据节点中，事务仅限于对单一数据库资源的访问控制，称之为本地事务。几乎所有的成熟的关系型数据库都提供了对本地事务的原生支持。但是在基于微服务的分布式应用环境下，越来越多的应用场景要求对多个服务的访问及其相对应的多个数据库资源能纳入到同一个事务当中，分布式事务应运而生。

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

本地事务

在不开启任何分布式事务管理器的前提下，让每个数据节点各自管理自己的事务。它们之间没有协调以及通信的能力，也并不互相知晓其他数据节点事务的成功与否。本地事务在性能方面无任何损耗，但在强一致性以及最终一致性方面则力不从心。

两阶段提交

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

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

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

柔性事务

如果将实现了 ACID 的事务要素的事务称为刚性事务的话，那么基于 BASE 事务要素的事务则称为柔性事务。BASE 是基本可用、柔性状态和最终一致性这 3 个要素的缩写。

在 ACID 事务中对一致性和隔离性的要求很高，在事务执行过程中，必须将所有的资源占用。柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性和隔离性的要求，只要求当整个事务最终结束的时候，数据是一致的。而在事务执行期间，任何读取操作得到的数据都有可能被改变。这种弱一致性的设计可以用来换取系统吞吐量的提升。Saga 和 TCC 都是典型的柔性事务实现方案。

结论

基于 ACID 的两阶段事务和基于 BASE 的最终一致性事务都不是银弹，可通过下表详细对比它们之间的区别。

缺乏并发度保障的两阶段事务不能称之为完善的分布式事务解决方案；而缺乏对 ACID 原义支持的柔性事务都甚至不能称之为数据库事务，它更适合服务层的事务处理。

放眼当前，实难找到无需权衡即可放之四海而皆准的分布式事务解决方案。

JDTX 的分布式事务解决方案

JDTX 的设计目标是强一致（支持 ACID 的事务原义）、高性能（甚至强于本地事务）、1PC（完全摒弃两阶段提交和两阶段锁）的完全分布式事务中间件，目前可用于关系型数据库。它采用完全开放 SPI 的设计方式，提供与 NoSQL 对接的可能，能够将多元异构数据维持在同一事务中。

设计理念

首先通过一张架构图来直观的了解一下 JDTX 的构成。

JDTX 由事务管理器（TM）和资源管理器（RM）组成。

事务管理器用于生成全局单调递增的事务日志序列号（LSN），事务的提交和回滚等核心流程处理，以及未提交事务的本地元祖（Tuple）持有。

资源管理器用于管理活跃事务数据。JDTX 的设计特点是将在事务中的数据（称之为活跃数据）和不在事务中的数据（称之为落盘数据）分离。活跃数据在落盘至预写日志系统（WAL）之后，并将数据保存至自研的多版本快照（MVCC）内存引擎中。落盘数据则是通过异步刷盘的方式，将 MVCC 引擎中的数据以流量可控的方式同步至最终的存储介质中（如：关系型数据库）。

事务内查询会将落盘数据和活跃数据合并，并根据当前事务的隔离级别获取出符合当前事务可见性的数据版本。

方案亮点

无损事务方案

JDTX 采用 WAL + MVCC 引擎的方式实现了事务的 ACID 原义。

原子性 & 一致性支持

JDTX 的 MVCC 引擎可以看做是一个集中式缓存，可以将两阶段提交简化至一阶段提交。维持单一节点中数据的原子性和一致性，即将分布式事务的范畴缩减到本地事务的范畴。

MVCC 引擎可以通过分片 + 主从同步的方式维持水平扩展和高可用的能力。JDTX 保证所有对事务数据的访问都通过 MVCC 引擎的活跃数据 + 最终数据端的落盘数据的合并的方式，以保证数据的原子性和一致性。

隔离性支持

JDTX 以多版本快照的方式实现事务隔离性。目前完整的支持 4 种标准隔离级别中的读已提交和可重复读，已经可以满足绝大部分需求。

持久性支持

JDTX 将事务的活跃数据在存入 MVCC 引擎之前先落盘至 WAL 引擎，以保证服务器崩溃，内存数据丢失时，活跃数据依然能够从 WAL 引擎中完全恢复。

高性能

JDTX 采用将活跃数据异步刷盘至数据库的方式极大的提高了数据写入的性能上限。它的性能瓶颈从数据库写入耗时转移到了落盘至 WAL 引擎和存储至 MVCC 引擎的耗时。

与数据库的 WAL 系统类似，JDTX 的 WAL 也采用日志顺序追加的方式，因此可以简单的理解为 JDTX 的 WAL 耗时 = 数据库系统的 WAL 耗时。而 MVCC 缓存则采用哈希数据结构，其写入耗时小于需要维护 BTree 索引的数据库写入耗时。因此，采用 JDTX 的事务方案，其数据更新性能甚至强于不开启事务。

另外，JDTX 采取了无 UNDO 日志的事务回滚策略。未提交的数据并不会进入 MVCC 引擎，而是被事务管理器本地持有。因此，只要清理掉未提交数据即可完成事务回滚。无 UNDO 日志的设计进一步的提升了事务处理的性能。

高可用

WAL 引擎和 MVCC 引擎均采用分片 + 主备的方式，以保证 JDTX 不会产生单点故障。在 MVCC 引擎完全不可用的情况下，可通过恢复模式将 WAL 中的数据同步至数据库，以保证数据的完整性。