技术与标准丨一种高性能的分布式事务及一致性复制实现

一种高性能的分布式事务及一致性复制实现

赵培  左奇

（中兴通讯股份有限公司，南京 210012）

摘要：GoldenDB作为一个面向海量数据处理场景下的分布式事务数据库，支持分布式事务，同时保证金融级的强一致、高扩展、高可用等特性。详细阐述了金融及电信场景下的高可用和一致性需求，设计并开发出一种高性能的分布式事务和一种Raft增强的一致性日志复制协议实现方案。

关键词：分布式数据库；分布式事务；高可用性；Raft；日志同步

1  引言

随着互联网经济的飞速发展，特别是抢红包、618、双十一等各种大规模促销场景的出现，传统的集中式数据库逐渐成为金融核心业务发展的瓶颈，迫使金融核心业务系统向分布式架构转型，利用分布式数据库替换集中式数据库，从而获得只有分布式数据库才具有的“海量数据处理场景下的高性能、高扩展、高可用”等关键特征。

21世纪以来，分布式数据库一直是业界研究的重点，主要围绕高可用、强一致、分布式事务、高可扩展、高性能等分布式数据库的核心关键特性展开研究，这些关键特性可能相互关联或者制约，比如根据CAP理论，一致性、可用性和分区容错性不可能同时满足。如何完整支持分布式事务又保证很高的数据读写性能，一直是分布式数据库的难点，很多NoSQL数据库（如HBase/Cassadra/MongoDB等）放弃支持分布式事务和SQL兼容来换取性能的提升。近年来，新型数据库NewSQL融合了一致性和可用性，正成为新的分布式数据库的研究热点，但因为分布式事务实现的复杂性，要么仅支持有限的分布式事务，要么以牺牲性能为代价，如Spanner、CockroachDB等。

2  基于Paxos/Raft等协议的数据库实现存在的缺陷

几乎所有的数据库系统都采用复制技术+高可用软件来保证数据的高可用性和持久性，如异步复制、同步复制、半同步复制^[1]等，这几种日志复制方式要么保证数据一致性而牺牲性能，要么提升了性能却无法保证数据不丢及数据一致性。而两阶段提交协议（2PC）^[2]虽可保证跨多个节点数据复制的强一致性，但因为两阶段提交需要数次网络交互和等待，导致整个分布式系统的性能显著降低；另外，两阶段提交容易因节点故障而导致两阶段提交被阻塞，严重影响系统可用性。Paxos^[3-4]、Raft^[5]、Chubby^[6]、ZooKeeper^[7]等共识协议的出现对解决分布式系统高容错场景下的强一致性、可扩展性提供了强有力的支撑，多种数据库采用了上述算法，如Spanner^[8]、MySQL^[9]、MongoDB^[10]等，但对多数派协议的严重依赖，意味着算法复杂度高、决策速度慢，虽经多种算法（如M-Paxos、FastPaxos^[11]、Multi-raft、MGR等）的改进，但基于Paxos/Raft等协议的数据库实现依然存在如下缺陷。

（1）Paxos/Raft协议基于两阶段提交进行设计而且逻辑复杂，虽可保证日志的强一致复制，但性能较差（时延大、吞吐量低），无法满足银行对跨数据中心（DC）高性能、强一致数据复制的需求。

（2）Paxos/Raft基于对等策略，无差别的自动选主可能将异地的候选节点选成新主，应用与数据库的异地分布将导致数据处理的性能极速衰减（时延增加、吞吐量衰减），但银行各数据中心资源实际是不对等的，主数据中心往往拥有最好的IT资源及运维服务保障力量，而异地数据中心可能仅具备数据备份而不具备业务接管能力，因此应优选主数据中心的副本为新主，其次是同城副本，最后才是异地副本。

（3）分布式数据库的每个数据分片都是一个独立的Paxos/Raft集群，自由的自动选主将导致各个数据分片的主节点漂移在多个数据中心，普通的查询请求变成跨DC的查询，从而导致分布式数据库性能严重下降。

（4）Paxos/Raft是基于多数派实现的一致性复制协议，一旦低于多数派不仅要停止服务而且无法进行自动选主，从而造成不可用。

（5）不稳定的网络异常容易诱发数据库停止服务的频繁发生，致使整个数据库集群进入自动选主阶段，导致系统可用性下降。

（6）Paxos/Raft等协议会占用更多的带宽，且对网络质量要求更高，需要租用更高带宽的网络，增加了跨数据中心的业务运维成本。

（7）银行只允许有限条件的故障自动切换（Failover），还必须支持手动切换，而标准Paxos/Raft协议各数据副本采用对等的自动故障恢复策略，不符合银行核心系统要求，缺乏对整体资源感知和选举控制策略等方面的考虑。

为了解决上述问题，本文提出了一种金融级分布式事务数据库的实现方案，具体做法如下。

（1）提出了一种高性能、低时延的分布式事务实现方案，总体性能与单节点事务相当，远高于标准的两阶段提交方式。

（2）设计了一种轻量级的自动选主算法和故障恢复机制，既借鉴了Raft等共识算法的异常监测和自动选主思想，又可规避标准Paxos/Raft协议所带来的日志复制性能差、故障恢复慢、不支持策略选主等问题。

3  分布式事务数据库GoldenDB的关键技术

分布式数据库产品GoldenDB采用无共享架构（Share Nothing），是一款具有银行基因的金融级分布式数据库。如图1所示，每个数据中心包含计算节点、数据节点、全局事务管理器（GTM Server）和GoldenDB管理节点。其中，GoldenDB的计算节点采用无状态化设计方式，负责接收用户发来的数据库操作请求，并进行SQL解析、SQL优化，生成分布式查询计划，再分发给各数据节点执行；GoldenDB的数据节点是在借鉴MySQL架构和接口基础上进行的重新设计和开发，深度优化了SQL引擎以及日志同步性能和可靠性，并在数据节点上部署代理软件（DBAgent）来强化数据库的自动化运维监控服务；GoldenDB的管理节点负责分布式数据库的管理及监控；GoldenDB的全局事务管理器（GTM Server）则提供分布式事务ID的申请、释放以及活跃事务列表的查询能力。

图1  GoldenDB部署架构

3.1  数据模型

GoldenDB采用关系型的数据模型，底层数据多节点存放每个节点上的数据按传统关系型数据库数据模型存储，这样便于节点的数据转移和复制。

（1）逻辑模型：GoldenDB将数据划分为多个数据分片，数据分片中各个表的划分主键可根据业务特性确定。因GoldenDB支持分布式事务处理，不限定表之间的分区键必须一致，但是合理的分区键设计可以有效地避免不必要的分布式事务，从而提升分布式数据库的整体性能。另外，GoldenDB通过一致性复制协议将数据复制到多个副本，保证了高可用性。GoldenDB中每张表有分区键，分区逻辑支持Hash、复制、List和Range。GoldenDB根据SQL中包含的表分片规则把语句下发到相应的数据节点。

（2）物理模型：每个数据节点根据数据分布规则存储业务数据。每个数据分片组内有一个副本为主副本，其他副本为从副本。主副本负责处理数据更新和查询，更新事务并以操作日志的形式将事务同步到各从副本；从副本接收主副本发送的事务日志并重放到本地数据库。通过读写分析从副本也支持读操作。

3.2  分布式事务

金融级分布式数据库GoldenDB对分布式事务的一致性要求很高，GoldenDB引入全局事务管理器（Global Transaction Manager）来管理全局事务的生命周期（创建、查询和释放等），如为每个全局事务分配全局唯一的自增序列ID，并基于全局事务ID（GTID）实现分布式事务间的原子性、一致性、隔离性，以及持久性。

3.2.1  读写事务

GoldenDB在两阶段提交方式的基础上进行性能优化，将全局事务拆分为多个在数据节点执行的子事务，各子事务直接在各数据节点执行并，在事务中记录全局事务ID，在事务管理器中对各数据节点的子事务执行结果进行汇总，如果所有子事务均执行成功，则事务就可以全局直接结束，并在全局事务中心标记该全局事务状态为已提交；如果有任何子事务执行失败，系统将根据之前在各数据节点提交的事务内容，自动构造反向补偿事务，并在所有成功提交的数据节点执行补偿事务。在一个正常运行的业务系统中，正常执行的事务比例远远高于异常事务，因此在大部分事务中都不需要执行补偿操作。而正常事务的前半部分由于多个子事务是在多个数据节点并发提交执行的，因此采用这种方法总体性能与单节点事务相当，远高于标准的两阶段提交方式。

GoldenDB基于GTID实现实时且一致的分布式事务。GoldenDB把协调全局事务参与者的职能与存储事务状态的职能进行分离，计算节点用于协调全局事务参与者执行事务操作，而全局事务管理器仅管理全局事务的状态。为了确保全局事务状态正常，全局事务管理采用了多种保障机制，例如实时持久性和多副本间实时同步等。GoldenDB事务管理架构如图2所示。

在每个分布式事务开始时，计算节点将请求发送到全局事务管理器（GTM Server），以便申请事务的GTID。GTID是全局唯一且单调递增的整数，被存储在GTM中，GTID申请成功后，称当前GTID所对应的事务是活跃事务，处于事务未提交状态。如果涉及数据更新，则将GTID信息更新到该事务要更新的数据中。成功提交事务后，计算节点将发送请求至GTM Server以释放GTID，释放成功后，该GTID所对应的全局事务已经提交，变成非活跃事务。任何节点发生事务提交失败，将触发该全局事务的回滚：发生故障的数据节点将自动回滚；事务已成功提交的数据节点，需要回滚到更新前的状态。所有节点回滚成功后，还需要释放该GTID。图2显示了已提交事务的回滚体系架构和过程。

图2  GoldenDB分布式事务实现原理

回滚模块部署在每个数据节点上，用于已提交事务的回滚。当某些数据节点无法提交时，计算节点将已提交事务回滚命令发送到已成功提交的数据库节点的回滚模块，命令中包含事务的GTID，回滚模块根据GTID执行回滚，具体步骤如下。

（1）定位：根据GTID相关信息定位待解析的数据库日志文件列表。

（2）查询：遍历数据库日志文件，查找与GTID对应的事务日志块。

（3）解析：解析日志块，为事务中的每个SQL语句生成反向SQL语句。

（4）执行回滚：以相反的顺序执行所有反向SQL语句，并确保它们在一个事务中。

由于回滚操作不是数据库的本机回滚机制，因此在实际使用中需要进行大量优化，以确保回滚性能达到可用水平。

3.2.2  只读事务

如图3所示，GoldenDB分布式数据库综合了几种并发控制技术的优点，采用了单机并发控制与全局并发控制相结合的方法实现了高性能的分布式分层并发控制方案：在存储节点中以基于加锁的并发控制为主，在分布式全局事务上使用单向递增序列号（全局事务ID）的并发控制。

图3  GoldenDB分布式MVCC原理图

为保证系统的实时读一致性与隔离性，本文设计实现了一种分布式数据库场景下的多版本控制机制（MVCC）。GoldenDB的数据节点接收到读请求后，数据节点首先获取当前全局的活跃事务列表，然后随子事务查询请求一起分发给各个数据节点进行数据查询处理，各个数据节点的多版本控制原理如下。

（1）依据数据节点本地的MVCC机制进行数据可见性判断。如果本地不可见，则说明全局也不可见，直接返回不可见；如果本地数据可见，继续下一步。

（2）如果本地可见，基于全局活跃事务列表进行数据全局可见性判断。如果全局可见，直接返回全局可见；如果全局不可见，说明该事务还处于全局活跃状态，继续下一步。

（3）如果全局不可见，数据节点查询Undo日志获取更老的历史版本。如果找到更老的历史版本，跳转至2，否则，返回不可见。

3.3  高可用实现方案

一方面，由于Mysql的半同步日志复制技术存在异步蜕变风险，且需借助第三方HA来实现自动选主及切换，存在数据丢失及故障切换时间较长的缺点；另一方面，Paxos/Raft虽可实现数据强一致性复制及自动选主，但其性能低的问题也被各方所诟病。为改善GoldenDB的高可用特性，本文提出一种创新的高性能强一致性日志复制技术，支持各种跨数据中心高可用部署方案（如同城、两地三中心等），可实现RPO = 0,RTO<30 s，远高于银保监会标准的要求（见图 4）。

图4  GoldenDB强一致日志复制架构

（1）自动选主：基于改进的Raft协议实现数据库集群的健康监测，一旦发现分片主节点异常，将基于Raft任期号+最新GTID集实现自动选主及故障切换。鉴于标准Raft的对等选主策略不符合银行要求，引入策略选主来引导具有最高优先级的候选节点当选主节点。

（2）日志强一致复制：基于中兴通讯自主研发的gSync日志复制技术实现高性能、强一致性日志复制，特别是WAN网环境下的日志复制进行了大量的优化。

（3）管控节点高可用：GoldenDB管理服务器采用高可用部署方案，确保GoldenDB元数据存储的强一致性和高可用性。

（4）数据服务封锁与路由控制：DBAgent会定期将各数据节点的健康状态上报给GoldenDB管理节点服务器，一旦GoldenDB管理服务器监测到某分片主节点异常，将立即指示计算节点去封锁该分片的读写服务，避免在主从切换期间造成数据不一致或者脏读；当该分片集群基于改进的Raft协议自动选主并主从切换成功后，新主节点上报新的集群状态信息给GoldenDB管理节点，GoldenDB管理服务器将解除该分片的读写封锁。

4   试验验证

本文的高可用强一致复制协议实现于分布式数据库GoldenDB数据节点的日志复制过程，试验分成两个部分：一是不同客户端连接数场景下的日志复制性能表现；二是容灾恢复测试。同时，测试中采用相同的软硬件环境，对MySQL的半同步和MGR日志同步复制方式也进行了对比测试。

测试服务器的配置信息为：CPU24 Core E5-2620v3@2.40GHz、内存 256G、储Intel DC P3600 2TB NVMe PCIe 3.0。IT及网络环境为：测试采用Sysbench（oltp.lua模型，16张表，每张表1000 万数据）测试；数据节点分别采用GoldenDB V5.0版本（gSync日志同步）和MySQL 5.7.19版本，采用3副本模式；日志复制采用半同步和MGR（MySQL Group Replication）两种模式。另外，虽然MGR既支持单主模式也支持多主模式，但由于MGR多主模式对网络质量要求很高，实际的两地三中心场景很难满足要求，因此本次的MGR测试采用单主模式、不限速模式。

4.1  正常情况测试

在同一个数据中心内部署三副本，网络响应时延低于0.1 ms，测试结果如表1所示。通过分析比对表1中的数据可得出如下结论。

（1）在低并发场景下，gSync日志同步的吞吐量略高于MGR和半同步；随着并发数的增加，gSync日志同步的吞吐性能优势逐渐显现，性能比其他两种复制方案超出20%左右。

表1  正常情况测试结果

表2  正常情况对比测试结果

（2）在3种日志复制方案中，gSync日志同步复制在高并发场景下的平均响应时延最低；随着并发数的增加，MGR的平均响应时延增长最快，显示出Paxos算法对日志复制的响应时延影响最大。

再将三副本部署在3个数据中心，数据中心间网络平均响应时延为10 ms，然后进行对比测试，测试结果如表2所示。通过分析比对表2中的数据可得出如下结论。

（1）随着并发数的增加，gSync日志同步的吞吐性能优势逐渐显现，性能比其他两种复制方案超出15%以上。另外，试验数据显示，时延增加将严重影 响MGR日志复制性能。

（2）gSync日志复制在高并发场景的平均响应时延最低，MGR最大，且随着并发量的增加，MGR的平均响应时延增长最快，显示出Paxos算法对响应时延有更大的影响。

4.2  异常情况测试

为了检验主节点故障后重新选主的效率，可在GoldenDB正常运行过程中终止主节点进程，并测试切换时间和选主时间。这时，故障上报时间与心跳监测的设置有关，故障发生3 s后，GoldenDB开始自动选主和故障切换，自动选主及故障恢复时间大约1 s左右（见图5）。

图5  主节点故障恢复

4.3  高低水位故障恢复时间

分布式数据库GoldenDB区别于其他分布式数据库的一个关键特征是：通过为GoldenDB设置两个高低副本响应数来应对复杂网络环境所导致的数据库不可用问题。

本次测试采用模拟两地三中心五副本部署方式，其中主数据中心部署副本1和副本2，同城数据中心部署副本3和副本4，异地数据中心部署副本5，设置gSync日志同步的高水位为3副本，gSync日志同步的低水位为2副本。系统正常运行后，首先断开异地数据中心网络，隔20 s后，断开同城数据中心网络，图6显示了该分布式数据库集群的吞吐量变化情况。由此可见，在两个数据中心都出现故障的恶劣场景下，GoldenDB依然可以保证可用性。

图6  数据中心级故障恢复图

5  结束语

针对金融行业的高性能的OLTP需求，本文设计了一种高性能的分布式事务实现方案，其性能远高于传统的两阶段提交事务实现方案。同时，为增强GoldenDB的高可用特性，本文还提出了一种高性能的强一致日志复制和恢复方案，吸收了Raft协议的异常监测和自动选主核心理念，既可保证银行级日志复制的强一致要求，又大大提升了数据库的高可用性；同时，采用高性能的gSync日志复制替换低性能的Raft日志复制方案，大大提升了日志复制的效率。通过试验验证GoldenDB在各种部署场景及异常情况下对系统性能的影响，证明了其日志复制和故障恢复的高效率。本文设计的高性能日志复制和故障恢复机制已经应用于某银行数据库系统中，其高性能日志复制和高效故障恢复算法具有很好的通用性，易应用于其他分布式数据库系统中。

参考文献

[1] Matthieu Robin. Pros and cons of MySQL replication types[EB/OL]. [2020-07-31]. https://dzone.com/articles/pros-and-cons-of-mysql-replicationtypes 2019 Feb.

[2] M.TamerÖzsu, Patrick Valduriez. Principles of distributed database systems[R]. 3rd Edition, Springer 2011.

[3] Lamport L. Paxos made simple[J]. ACM SIGACT News, 2001,32(4):18-25.

[4] Lamport L. Fast paxos[J]. Distrib Compute, 2006,19(2):79-103.

[5] Ongaro D, Ousterhout JK. In search of an understandable consensus algorithm: Proceedings of the 2014 USENIX Conference on USENIX Annual Technical Conference[C], 2014:305-319.

[6] Burrows M. The chubby lock service for loosely-coupled distributed systems: Proceedings of the 7th Symposium on Operating Systems Design and Implementation[C],2006:335-350.

[7] Apache ZooKeeper. ZooKeeper website[EB/OL].[2020-07-31].http:// zookeeper.apache.org/.

[8] Corbett JC, Dean J, Epstein M,et al. Spanner: Google’s globally-distributed database[J]. ACM Trans. On Computer Systems,2013,31(3):251-264.

[9] Baron Schwartz, Peter Zaitsev, Vadim Tkachenko. High performance MySQL: optimization, backups, and replication[R]. 3rd Edition-O’Reilly Media,2012.

[10 ] Kristina Chodorow. MongoDB: the definitive guide[R], 2nd Edition-O’Reilly Media, 2013.

[11] Jinwei Guo1, Jiajia Chu1, Peng Cai1, et al. Lowoverhead paxos replication[EB/OL]. [2020-07-31].https://link.springer.com/article/10.1007/s41019-017-0039-z.

A high-performance distributed transaction and consistent replication implementation

ZHAO Pei, ZUO Qi

(ZTE Corporation,Nanjing 210012, China)

Abstract: As a distributed transaction database for massive data processing scenarios, GoldenDB supports distributed transactions while ensuring financial-level strong consistency, high scalability, and high availability. This article introduces the high availability and consistency requirements in the financial and telecommunications scenarios, develops a highperformance distributed transaction and a Raft-enhanced implementation of a consistent log replication protocol.

Key words: distributed database; distributed transaction; high availability; Raft; log synchronization

本文刊于《信息通信技术与政策》2020年第11期

主办：中国信息通信研究院