PolarDB-X 致数据库行内人 (一) 如何有效评测国产数据库的分布式事务

分布式事务评测缘起

近段时间，一直在参与国内金融行业的分布式数据库选型测试工作，围绕银行内部的实际业务场景进行验证。遇到了一个比较有意思的案例。

前期在联机业务场景测试中，各大数据库厂商在事务测试上都比较顺利，在功能和性能角度都很好的满足了业务要求。 但在跑批业务场景的测试中，个别数据库厂商就遇到了分布式事务的一致性问题(会读到分布式事务中间状态的数据)，而该厂商通过了行业的各项事务测评认证，因此展开了如何有效评测国产数据库事务一致性的话题，需要大家辩证的思考下。

本文是系列文章的第一篇，介绍第一个重要话题：“数据库的分布式事务”，这也是目前普通用户面对分布式数据库产品介绍问的最多的一个内容，如何有效评测分布式事务也是一个非常重要的能力。致敬同行，我们将PolarDB-X事务架构设计上的一些思考和测试方式，做了整理和梳理，期望能对大家更好的理解分布式事务的测试有所帮助。

这些所谓观点并无谁对谁错之分，仅仅代表我们的思考。如果你有任何想说的，也欢迎在评论区与我讨论。

金融行业通用测评

近年来国内自主可控诉求越来越强烈，国内数据库行业蓬勃发展，诞生了很多创业型公司，国家层面也出台了一系列的数据库评测标准，大体分为集中式和分布式数据库的测评。 中国人民银行在2020年发布了一个行业标准，《分布式数据库技术金融应用规范 技术架构（JR/T 0203-2020）》 关于分布式事务测试的描述：

分布式数据库金融标准，是分布式数据库行业中最完整的标准之一，给出了对于分布式数据库的事务ACID测试的指导性意见。

机构测试设计的测试用例，普遍会采用模拟数据库故障方式来验证分布式事务，细分一下场景：

1. 模拟数据库多副本的重启，可以验证数据库事务的持久性 (ACID中的D)
2. 模拟主机的异常故障(断网、IO Hang等)，可以验证数据库事务的原子性 (ACID中的A)
3. 采用SQL交互，设置不同的数据隔离级别，开多个链接，手工验证事务的隔离级别 (ACID中的I)
4. 比如运行TPC-C 或者 特定的转账测试，在数据导入完成、以及程序运行完成后，运行几条一致性校验的SQL来验证数据的一致性 (ACID中的C)

整个测评方案更多是围绕事务ACID，进行了比较全面的覆盖型验证，但从数据库内核研发的视角视角、以及金融行业实际业务场景的实测来看，还是有一定的局限性，否则也不会出现通过分布式数据库金融行业认证，但无法通过金融行业实际业务场景的测试验收。

PolarDB-X的设计和思考

事务是一切的基础

先抛开分布式数据库，我们首先思考一个通用数据库的话题： 数据库事务在哪些地方影响了业务使用？ 我们拿一个银行的转账场景做一下例子：A账户余额有100元，B账户余额0元，在这个基础上A向B转账40元 复盘常见的业务场景：

• 在线联机业务，通过事务ACID机制，需要保证A向B转账过程中的数据一致性，满足任意时刻A和B上的账户总余额为100
• 数据库备份和恢复，按时间点的恢复(point-in-time recovery)目前也是行业的共识需求，我们需要确保恢复出来的备份集数据，满足A和B上的账户总余额为100

这也是目前行业测试过程中常见的关注场景，但结合业务场景思考一下，还远不止，比如：

• 跑批业务，典型的ETL机制，通过数据的全量读取和批量写入，为满足业务处理效率，很多数据库厂商会提供旁路导入和导出的机制，同样需要满足事务的总余额为100。旁路导出例子：select * from user partition(p1) order by id desc limit 10,10，每个分片数据单独做分页排序，减少分布式的分页排序代价。
• flashback query，典型的数据快速恢复场景，oracle基于MVCC多版本提供了AS OF Timestamp语法，可以快速读取一个历史的事务数据版本，结合insert into xxx select xx as of timestamp '10分钟前'可以快速恢复出业务误操作的数据。
• 读写分离 or follower read，典型的技术架构场景，比如paxos/raft的三副本，很多数据库厂商会提供follower read的能力，本质上就是一种读写分离的架构，同样需要满足事务的总余额为100。需要注意：事务的一致性读 和 多副本下的数据复制延迟带来的数据不一致读，这是两个不同的概念。比如；数据延迟只是让我们读到1秒钟之前的事务数据，但1秒前的数据读取总余额时也要为100，不能读到40或者140的中间状态
• 容灾架构(两地三中心、同城3AZ)，典型的容灾架构场景，比如考虑两地三中心的极端场景，中心地域挂了，切换到异地机房，异地机房的数据可以有延迟(RPO>0)，但需要事务粒度的一致性，满足A和B上的账户总余额为100
• 主备复制 or CDC(mysql binlog订阅)，典型的数据增量复制的场景，常见于数据库的binlog增量日志，部署异地多活复制，同样需要需要保证事务的一致性，在外置复制增量数据的情况下，满足A和B上的账户总余额为100(查询数据仓库 或者 异构的备库)
• HTAP架构，常见的数据库实现为采用多份数据副本的方式，通过行转列构建异步的列存副本，虽然数据行转列会有延迟，但查询到列存副本时同样需要考虑事务的一致性，即使读取1秒前的数据也要满足总余额时为100。

大家可以辩证的思考一下，这部分的业务场景在传统的单机数据库事务中是一个默认能力，但在分布式事务中绝不是一个简单的ACID机制，还需要有更多的顶层设计，一句话总结：事务是一切的基础，影响重大

举一个反例子来看，常见于传统的分库分表的事务架构，可以通过开源MySQL或者PG的主备强复制、两阶段的事务提交，可以一定程度的满足ACID的定义，但在遇到其他业务场景会事务一致的局限性：

1. 指定时间的备份恢复，因缺少任意时间点的一致性视图，导致无法满足一致性恢复。变种的方法：定时做高频的一致性快照，比如每各30秒备份一次全局活跃事务链表，可以达到恢复到30秒的粒度
2. 联机和跑批混合场景，跑批场景读取全量数据过程中，因缺少一致性的视图，会有机会读取到事务提交阶段的状态。变种的方法：跑批场景不能做旁路，全量数据拉取都得经过全局活跃事务链表来判断

分布式事务方案

目前分布式事务常见方案：