【分布式理论11】分布式协同之分布式事务（一个应用操作多个资源）：从刚性事务到柔性事务的演进

之前我们了解分布式系统中的互斥问题及其解决方案（分布式锁）。互斥问题讨论的是多个进程对同一个临界资源进行操作的问题，而本文将要讨论的是同一个进程对多个临界资源进行操作的问题。

一. 什么是分布式事务？

简单来说，分布式事务就是跨多个独立的资源（比如数据库）进行的事务。

举个例子，假设一个银行系统需要处理一次转账操作：从A账户转出100元分别到B账户30元、C账户70元。这种操作不仅仅涉及到一个数据库，而是涉及多个资源（A账户、B账户、C账户）。这个转账操作要么完全成功，所有的账户变动都要完成；要么完全失败，没有任何账户被修改。类似这样的跨多个资源的事务，我们称之为分布式事务。

 

二. 分布式事务的挑战

在分布式系统中，跨多个服务和数据库执行的事务面临以下几个挑战：

• 一致性问题：如何保证数据在多个系统中保持一致？
• 网络故障：网络不稳定可能导致事务执行失败，如何保证事务不会中途丢失或被错误提交？
• 并发冲突：多个服务之间并发执行的事务如何互不干扰？

为了处理这些挑战，分布式事务采用了不同的理论和技术框架来确保数据一致性、可用性和事务的正确性。

 

三. 事务的ACID特性

分布式事务的核心目标是保证事务的一致性和完整性，这与单体应用中的ACID特性密切相关。ACID是事务管理的基本要求，包含以下四个特性：

• 原子性（Atomicity）：事务中的所有操作要么全部成功，要么全部失败，不能部分成功。
• 一致性（Consistency）：事务执行前后的数据一致，系统从一个一致性状态转变到另一个一致性状态。比如：从 A 账户转出 100元，B 账户中到账 30 元，C 账户中到账 70 元。完成这个事务操作以后，A 账户减少的钱数与 B、C 账户增加的钱数总和应该是一样的，都是 100 元。
• 隔离性（Isolation）：并发执行的事务互不干扰，每个事务对外界是隔离的。
• 持久性（Durability）：一旦事务提交，数据更改就会永久保存，即使系统崩溃也不丢失。

在单体架构中，ACID特性易于实现，但在分布式系统中，由于网络延迟、节点故障等问题，保证强一致性变得困难。此时，我们需要更灵活的解决方案。

 

四. CAP理论与BASE理论

1. CAP理论

1.1. 三大特性

在分布式系统中，由于网络和硬件的限制，无法同时保证一致性、可用性和分区容错性，这就是著名的CAP理论的核心思想。CAP理论提出，在一个分布式系统中，最多只能保证以下两个特性：

• 一致性（Consistency）：所有节点的视图是相同的，保证每个节点的数据在同一时刻一致。
  

• 可用性（Availability）：可用性是指在分布式系统中，即使一部分节点出现故障，系统仍然可以响应用户的请求。

• 分区容错性（Partition tolerance）：假设两个数据库节点（每个节点数据一致）分布在两个区，而这两个区的通信发生了问题，因此无法达成数据一致，这就是分区问题，此时需要从一致性和可用性之间做出选择。是选择一致性（C）​，等待两个区的数据同步了再去获取数据，还是选择可用性（A）​，只获取其中一个区的数据？

 

1.2. 三者不能兼得

CAP理论表明，当网络分区发生时，分布式系统必须在一致性和可用性之间做出选择。如下例子：

业务代码对两个节点的通信失败，往数据库 01 写入记录 A 时，需要锁住数据库02 中的记录 A，不让其他业务代码修改此纪录，直到数据库 01 修改完成。一致性和可用性在此刻是矛盾的，不能兼得。

保证特性	放弃特性	适用场景	说明
一致性、可用性	分区容错性	不适用（无法实现）	如果放弃分区容错性，就等于放弃使用分布式系统，即单体。
一致性、分区容错性	可用性	金融领域（如银行、支付系统等）	需要保证数据一致性，甚至在网络分区时也要牺牲系统可用性，保证交易数据的正确性和一致性。
可用性、分区容错性	一致性	ToC端应用（如电商网站、社交平台等）	强调用户体验，牺牲部分一致性以换取系统高可用性，允许数据暂时不一致。适合大流量和高并发的应用场景。

 

2. BASE理论

由于 CAP 理论导致一个应用同时至多只能支持两个特性，无法三全其美，且高并发系统追求的往往是可用性，因此对 CAP 理论进行进一步扩充，产生了 BASE 理论。

特性	说明	举例
基本可用性	系统能够在流量激增或节点故障时，通过限流或降级保证用户请求可用。	电商系统在流量激增时，优先保证核心业务（如订单处理），将非核心业务降级处理。
软状态	数据副本之间允许存在短时间的数据不一致，容忍数据同步延迟。	数据库01中记录A写入后，数据库02中的记录B会在一定延迟后同步，而不是立即同步。
最终一致性	数据在短时间内可能不一致，但过了一段时间后，数据会最终达到一致。	在分布式系统中，数据副本可能会在网络延迟时出现不一致，但经过一段时间，数据会同步一致。

BASE理论强调的是最终一致性，而不是传统数据库中的强一致性。它适用于那些需要高可用性和容忍短期不一致的系统，例如电商平台和社交网络。

 

五. 分布式事务解决方案

为了在分布式系统中保证事务的正确性，业界提出了多种分布式事务解决方案，常见的有两阶段提交（2PC） 和 TCC（Try、Confirm、Cancel）。

1. 两阶段提交（2PC）

**两阶段提交协议（2PC）的基本思想是通过协调者（Transaction Manager）和参与者（Resource Manager）来控制事务的提交或回滚。2PC的工作过程分为两个阶段：

 

准备阶段：

事务协调者（事务管理器）询问每个参与者是否准备好，马上要执行事务了。事务参与者会根据自身业务和资源情况进行检查，然后给出反馈。

检查过程根据业务内容的不同而不同，例如订票业务需要检查是否有剩余票、扣款业务需要检查余额是否足够。只有检查通过，才能返回就绪（ready）信息。否则，事务将终止，并且等待下次询问。由于检查过程需要完成一些操作，因此需要写 redo 日志和 undo 日志，以便事务失败重试，或者失败回滚时使用。

 

提交阶段：
如下图：如果事务协调者接收到事务参与者检查失败或者超时的消息，会给其发送回滚（rollback）消息，否则发送提交（commit）消息。

以下是整理后的两种情况的处理过程：

情况	步骤
情况 1：事务回滚	条件：只要有一个事务参与者反馈未就绪（no ready），事务协调者会回滚事务。
	1. 事务协调者向所有事务参与者发出回滚请求。
	2. 事务参与者使用第一阶段的 undo 日志信息执行回滚操作，并释放事务期间占用的资源。
	3. 各事务参与者向事务协调者反馈应答（ack）消息，表示完成回滚操作。
	4. 事务协调者接收到所有事务参与者的应答消息，即完成事务回滚。
情况 2：事务提交	条件：当所有事务参与者均反馈就绪（ready）消息时，事务协调者会提交事务。
	1. 事务协调者向所有事务参与者发出正式提交事务的请求。
	2. 事务参与者执行提交（commit）操作，并释放事务期间占用的资源。
	3. 各事务参与者向事务协调者反馈应答（ack）消息，表示完成提交操作。
	4. 事务协调者接收到所有事务参与者的应答（ack）消息，即完成事务提交。

尽管2PC简单易理解，但它存在问题，比如在网络分区或故障情况下，可能会导致事务挂起，无法继续提交或回滚，造成数据不一致。

 

2. TCC（Try-Confirm-Cancel）

TCC（Try-Confirm-Cancel）的核心思想是对于每个资源的原子操作，应用程序都需要注册一个与此操作对应的确认操作和补偿（撤销）操作。其中确认操作负责在原子操作执行成功时进行事务提交，补偿操作负责在原子操作执行失败时对事务进行回滚。

 

TCC协议分为三个阶段：

• Try阶段：进行资源的预检查和预留，确保资源可用。
• Confirm阶段：负责对业务系统做确认提交。如果 Try 阶段执行成功，表明针对资源的操作已经准备就绪，此时执行 Confirm 便会提交对资源的操作。也就是说当资源准备好时，只用提交该操作执行就好了。
• Cancel阶段：负责在业务执行错误，需要回滚时执行业务取消操作，此时就需要释放 Try 阶段预留的资源了。换句话说，是在资源操作执行失败的情况下，根据之前预留的资源情况进行回滚。

 

TCC协议通过提供灵活的补偿机制，能够在事务失败时进行回滚，保证系统的一致性。

例子：
假设有一个转账服务，需要把 A 银行中 A 账户的 100 元分别转到 B 银行的 B 账户和 C 银行的 C 账户，这三个银行的转账服务各不相同，因此这次转账服务就形成了一次分布式事务。

阶段	操作描述	具体步骤
Try 阶段	检测资源是否可用，验证所有参与者的资源可用性，并记录相关信息。	1. 检查 A 账户余额是否大于 100 元。 2.记录 A 账户的总金额、转出金额。 3. 记录 B、C 账户的总金额、转入金额。 4. 在数据库中保存相关字段（如余额、转出金额）。 5. 如果资源可用，进入 Confirm 阶段；如果不可用，回滚。
Confirm 阶段	执行具体的转账逻辑，进行资源更新，并设置事务的成功状态。	1. 从 A 账户扣除 100 元，更新余额为 220 - 100 = 120。 2. 更新 B 账户余额为 50 + 30 = 80，C 账户余额为 60 + 70 = 130。 3. 更新交易状态为转账成功。 4. 向所有参与者发出确认提交请求，确认各方操作。
Cancel 阶段	回滚操作，恢复资源到原始状态。	1. 如果 Try 阶段失败或资源无法提供，回滚所有操作。 2. A 账户恢复扣除的 100 元，余额为 120 + 100 = 220。 3. B 账户和 C 账户分别恢复相应的金额，B 账户恢复为 80 - 30 = 50，C 账户恢复为 130 - 70 = 60。 4. 事务回滚并释放占用的资源。

 

六. 小结

分布式事务的出现带来了很多挑战，但也推动了事务管理理论和实践的不断发展。从ACID特性到CAP理论、BASE理论，再到DTP、2PC和TCC等分布式事务协议，每一种理论和方案都在不同的应用场景中发挥着重要作用。

在实际开发中，选择哪种分布式事务方案应根据业务需求、系统架构、性能要求等因素来决定。对于高一致性要求的金融类系统，2PC可能更合适；而对于电商类高并发系统，TCC和BASE理论的结合则能提供更高的可用性和灵活性。