技术资讯：分布式事务

Posted 2021-04-25 ECP微服务

在《微服务架构与ECP》一文中，提到微服务面临着分布式事务的挑战。本文就这个问题，与大家进行一些关于分布式事务知识学习与探索。
事务是由一组操作构成的可靠、独立的工作单元。具有ACID特性，即Atomicity(原子性)、Consistency(一致性)、Isolation(隔离性)、Durability(持久性)。说的简单一点就是所有操作要么成功，要么回到初始状态。这个难点就是在高度并发、资源分布、大时间跨度的环境下，如何保证高性能运行。
对于分布式事务，目前业界的解决方案，一种是两阶段提交，一种就是事务补偿，还有一种是复合模式（TCC模式）。下面分别介绍这三种方案。

1、 两阶段提交：所谓的两个阶段是指：准备阶段和提交阶段。见下图：

将提交分成两阶段进行的目的很明确，就是尽可能晚地提交事务，让事务在提交前尽可能地完成所有能完成的工作，这样，最后的提交阶段将是一个耗时极短的微小操作，这种操作在一个分布式系统中失败的概率是非常小的，也就是所谓的“网络通讯危险期”非常的短暂，这是两阶段提交确保分布式事务原子性的关键所在。这也是一种实时一致性的事务模式，具备通用性的特点，所有分布式应用在不更改业务的前提下，都可以使用这种模式。但是它的缺点也同样明显：带来协议成本、准备阶段的持久成本、全局事务状态的持久成本、潜在故障点多带来的脆弱性、准备后，提交前的故障引发、一系列隔离与恢复难题。说得简单一点，就是性能不高，为了保证0.1%失败操作安全，而浪费了99.9%正常操作的性能。

2、 事务补偿：事务补偿机制即在事务链中的任何一个正向事务操作，都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链，则必须事务链中的每一个业务服务或操作都有对应的可逆服务。这种事务机制，允许数据暂时的不一致性，但是数据会最终一致性。BASE（BA：Basic Availability、S： Soft state、E： Eventuall consistency）策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现了两个服务的真正解耦，解耦的关键就是异步消息和消息持久化机制。见下图：

业务活动的主动方，在完成业务处理的同一个本地事务中，记录消息数据、业务处理事务提交后、通过消息服务通知业务被动方，通知成功后删除消息数据；消息恢复系统定期找到未成功发送的消息，交给消息服务补发送。这种方式必需保证消息服务的可靠性，在业务服务调用的时候，必需保证业务服务的幂等性（重复调用多次产生的业务结果与调用一次产生的业务结果相同）。这种方式，也可以叫分段式事务。很明显， 每一个事务域的性能都很高，这充分保证系统的可用性，牺牲了一致性。这种事务的场景也经常有，比如银行周六转款，客户可能下周一才得到通知到账。这种模式降低了用户体验，需要考虑用户的容忍程度。

3、 复合模式（TCC模式），TCC是Try － Confirm － Cancel，一个事务也是分成两个阶段提交，但是在Try操作可以灵活选择业务资源的锁定粒度。而不是由数据库控制。这种业务资源的锁定必需是可以事务补偿的，当进行Cancel时候，能进行回退。见下图：

Try: 尝试执行业务，完成所有业务检查(一致性)，预留必须业务资源(准隔离性)；Confirm:确认执行业务，真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源，Confirm操作满足幂等性；Cancel: 取消执行业务，释放Try阶段预留的业务资源，Cancel操作满足幂等性。这种模式能在一致性（准一致性）与可用性中获得比较好的平衡，但是有比较高的开发成本。
上面介绍的几种模式，各有利弊，必需考虑具体的应用场景。企业应用使用第一种模式是主流；对于互联网应用，第三种是主流，高并发的核心业务也使用第二种。对于微服务架构，推荐第三种模式，因为“平衡”是一个很好的理由。