DRDS 柔性事务漫谈

摘要： 在阿里巴巴，“柔性事务” 已是重构分布式事务的标准方法，覆盖了商品、交易、支付各个大规模应用场景，而且经受了双十一的考验。

DRDS 是阿里云提供的一款分布式数据库产品，它的原型是在阿里内部使用了 10 年的数据库中间件 TDDL。DRDS 在 TDDL 提供的数据切分和 SQL 路由能力上，强化了分布式查询，事务和水平扩容能力。

什么是柔性事务？

在分布式数据库中，数据存储在多个节点将引入两个问题：

• 分布式事务 - 业务须要更新多个节点的数据。
• 全局二级索引 - 查询没法准确的定位数据位于哪一个节点。

因为全局二级索引的同步依赖于事务，所以 分布式事务 是全部分布式数据库产品都须要解决的核心问题。这一问题的关键是 —— 数据存储在多个节点，本来在单机数据库上不难实现的 ACID 特性在分布式环境下变得困难：

1. 由于网络通讯的不可靠，事务的原子性须要用屡次日志和网络通讯来保证。
2. 存储节点的增长，放大了单个存储节点在事务过程当中出现故障的风险。
3. 用锁实现的事务隔离性，在故障或网络抖动时严重影响性能。

所以，在高可用与高性能的应用场景，分布式事务的最佳实践是放弃 ACID，遵循 BASE 的原则重构业务流程：

区别于 ACID 特性的数据库事务，这种放弃强一致性，采起最终一致方式执行的分布式事务称为 “柔性事务” (Flexible Transactions)。

在阿里巴巴，“柔性事务” 已是重构分布式事务的标准方法，覆盖了商品、交易、支付各个大规模应用场景，而且经受了双十一的考验。阿里内部最经常使用的柔性事务方案有 “消息事务” 与 “TCC 事务” (Try / Confirm / Cancel)，它们的基本原理是一致的：

1. 将业务中的分布式事务分解成一个个在独立分库上执行的子事务。
2. 用异步重试的方式执行这些子事务，由框架或应用保证重试的 “幂等”（相同的业务逻辑不会被重复执行）。
3. 若是须要回滚，以一样方式执行另外一组子事务组成的补偿操做，恢复事务前的业务状态。

柔性事务放弃了隔离性，减少了事务中锁的粒度，使得应用可以更好的利用数据库的并发性能，实现吞吐量的线性扩展。异步执行方式能够更好的适应分布式环境，在网络抖动、节点故障的状况下可以尽可能保障服务的可用性 (Availability)。所以在高可用、高性能的应用场景，柔性事务是最佳的选择。

可是，现有的柔性事务方案都存在一个共同问题：它们是以框架或者中间件的形式存在，应用须要付出较大的改形成本：

1. 框架和中间件的接口带来了学习成本。
2. 用户须要理解一些概念（例如 “可靠消息” “幂等”）才能正确的使用。
3. 须要业务流程去适配工具，应用不但在架构上要大幅调整，并且还影响业务流程的直观性。

有没有更好的方案？

有。 DRDS / TDDL 在新发布的 5.3 版本开始提供两种类型的分布式事务：柔性事务 (FLEXIBLE) 和两阶段提交事务 (XA)。前者将柔性事务与传统数据库的使用方式相结合，提供了简单易用、低成本、高性能的 DRDS 分布式事务功能。

使用 DRDS 柔性事务

开启 DRDS 柔性事务只须要一行代码：

SET drds_transaction_policy = 'flexible';

SHOW VARIABLES LIKE 'drds_transaction_policy'; 
+-------------------------+----------+
| VARIABLE_NAME           | VALUE    |
+-------------------------+----------+
| drds_transaction_policy | FLEXIBLE |
+-------------------------+----------+
1 row in set (0.07 sec)

除了一行代码，DRDS 柔性事务的使用方法和普通事务彻底相同：应用首先用 SET autocommit = 0和 SET drds_transaction_policy = 'flexible' 开启柔性事务；而后在同一个会话中执行事务的 SQL 语句 —— 最后当应用发起 commit 或 rollback 后，DRDS 将保证这些 SQL 语句执行的原子性：所有成功，或者所有失败。

相比 TCC 或消息事务, DRDS 不须要业务编写补偿操做的回滚语句。DRDS 会根据事务中 SQL 语句的语义，自动生成相应的补偿操做。

例如，若是业务执行的是一条典型的资金扣减操做：

UPDATE account SET balance = balance - 100 WHERE id = 123 AND balance >= 100

DRDS 会自动生成对应的反向退款操做：

UPDATE account SET balance = balance + 100 WHERE id = 123

因为柔性事务的弱隔离性，应用一般会担忧：提交失败后，异步回滚操做是否会覆盖并发的更新，形成 "Lost update" 或者 “回滚覆盖” 问题。在传统 TCC 或消息事务中，回滚覆盖问题须要由应用引入状态、版本号、或乐观锁机制来规避。

DRDS 柔性事务则使用了一些创新的方式来解决这个问题：

1. 增量回滚

前面的例子已经展现了增量回滚是如何工做的：若是 DRDS 识别应用的 UPDATE 语句中包含 “增量操做”，例如：balance = balance - 100，则会在回滚语句中使用 balance = balance + 100 进行补偿。因为增量操做的结果与顺序无关，即便事务异步回滚，也不会覆盖任何一笔业务的更新结果。

增量操做的定义是 UPDATE 语句符合如下格式：

UPDATE {表名} SET {列名} = {列名} [+/-] {常量表达式}, ... WHERE {条件表达式}

增量回滚对帐户、积分、库存这样的字段很是有用，而这些字段又一般是须要用分布式事务严格保证一致性的关键数据。建议在应用中尽可能对这一类字段采用 “增量操做” 的方式更新，既节省了一次数据库操做（SELECT)，又避免了柔性事务 “回滚覆盖” 的风险。

2. 关键事务

另外一个防止回滚覆盖的方法是 “关键事务”。

在 DRDS 柔性事务中，应用第一次在事务内执行的 DML(INSERT/UPDATE/DELETE) 操做被放入 “关键事务” 内执行。在柔性事务的执行流程中，“关键事务” 老是第一个开始，最后一个提交。

DRDS “关键事务” 的执行机制与单机事务相同，不须要记录补偿操做，也不须要异步回滚。所以，把具备回滚覆盖风险的 UPDATE 操做放入 “关键事务” 内执行，是一个防止异步回滚的好方法。

“关键事务” 的设计，可让一个 DRDS 单机事务天然切换到分布式事务。在传统的柔性事务方案中，应用须要识别业务场景是否是存在分布式事务，而后再根据场景采用不一样的事务方式。而 DRDS 的特殊设计，能够作到开启柔性事务，执行单机事务也不产生任何额外代价。

3. 后置执行

第三个方法是使用 “后置执行” 优化事务流程，防止产生回滚。

DRDS 提供了一个全新的 SQL 执行方式：“后置执行”。用来优化分布式事务中不影响业务最终执行结果的跨库操做。在分布式事务理论中，这一类优化被称为 “Best Efforts 1PC”：

使用 “后置执行” 很是简单，只须要在 SQL 语句的头部加入 /*TDDL:DEFER*/:

/*TDDL:DEFER*/ UPDATE account SET balance = balance + 100 WHERE id = 123

DRDS 保证后置执行的 SQL 仅仅执行一次，不须要应用关心出错重试或者幂等的问题。

“后置执行” 将事务中同步执行的操做转移至异步执行，减小了分布式事务中持有锁的时间，提升了事务执行的并行度，所以能够很好的提高分布式事务的性能。同时，因为 “后置执行” 用异步重试替代了回滚，它也是解决回滚覆盖问题的另外一个方法。

使用 DRDS XA 事务

新版本 DRDS 也支持 XA 事务，在柔性事务的基础上提供了强一致能力。

SET drds_transaction_policy = 'XA';

SHOW VARIABLES LIKE 'drds_transaction_policy'; 
+-------------------------+-------+
| VARIABLE_NAME           | VALUE |
+-------------------------+-------+
| drds_transaction_policy | XA    |
+-------------------------+-------+
1 row in set (0.07 sec)

DRDS XA 事务使用两阶段提交协议 (XA Protocol) 保护子事务的提交与回滚，消除了柔性事务的异步回滚问题。因为 XA Protocol 在提交与回滚阶段始终加锁，避免了事务结束前的脏读和覆盖，可是对性能有较大影响。

“后置执行” 功能在 DRDS XA 事务中一样可用，可以减小 XA 协议中的锁，提供了进一步的性能优化空间。

因为 MySQL XA 实现机制的限制，咱们建议只有在 DRDS 后端是 MySQL 5.7 版本以上才启用 XA 事务功能。

低成本、高性能

从稳定性和成本出发，DRDS 柔性事务不引入额外的服务和存储节点，而是利用后端的 RDS/MySQL 存储事务日志和回滚信息。在实现上，DRDS 尽量的减小了事务过程当中的数据传输和日志开销，以提高分布式事务的性能。

使用 sysbench 压测工具代表，在标准的 8core 16G 规格 DRDS 实例上，开启柔性事务能够达到 9000 QPS 的优异性能。相比不开启事务的 sysbench 压测结果，性能差别不到 10%.

小结

从分布式事务的原理出发，最终一致的 “柔性事务” 与提供 ACID 保证的 “强一致事务” 是两个独立的发展方向。前者实现了更高的水平扩展能力与性能，代价是应用须要付出额外的开发成本；后者提供了强一致的数据访问和更好的开发体验，但存在性能上的限制。

做为行业领先的云原生分布式数据库，DRDS 同时在两个方向拓展产品的边界：

• 下降应用使用 “柔性事务” 的开发成本。
• 持续创新，提高 “强一致事务” 的性能和扩展性。

DRDS 新版本提供的分布式事务功能（柔性事务以及 XA 事务）正是第一阶段的成果。

将来的 DRDS 产品将为企业用户提供更多、更好的选择：做为基础的 “强一致事务”、标准的全局事务隔离级别、基于分布式 MVCC 的一致性读、以及为高性能应用提供的 “柔性事务” 。在默认配置下，DRDS 将提供标准的事务 ACID 保证，以及高于业界水准的性能；而应用只须要付出较少的代价，就能够适配 DRDS 的特性，得到更高的水平扩展能力和性能保证。

原文连接