从本地事务到分布式事务的演变

什么是事务？回答这个问题之前，我们先来看一个经典的场景：支付宝等交易平台的转账。假设小明需要用支付宝给小红转账 100 元，此时，小明帐号会少 100 元，而小红帐号会多 100 元。如果在转账过程中系统崩溃了，小明帐号少 100 元，而小红帐号金额不变，就会出大问题，因此这个时候我们就需要使用事务。本地事务通过 ACID （Atomicity（原子性），Consistency（一致性），Isolation（隔离性），Durability（持久性））保证数据的强一致性。

随着业务的高速发展，面对海量数据，例如，上千万甚至上亿的数据，查询一次所花费的时间会变长，甚至会造成数据库的单点压力。因此，我们就要考虑分库与分表方案了。分库与分表的目的在于，减小数据库的单库单表负担，提高查询性能，缩短查询时间。这里，我们先来看下单库拆分的场景。事实上，分表策略可以归纳为垂直拆分和水平拆分：

• 垂直拆分，把表的字段进行拆分，即一张字段比较多的表拆分为多张表，这样使得行数据变小。一方面，可以减少客户端程序和数据库之间的网络传输的字节数，因为生产环境共享同一个网络带宽，随着并发查询的增多，有可能造成带宽瓶颈从而造成阻塞。另一方面，一个数据块能存放更多的数据，在查询时就会减少 I/O 次数。
• 水平拆分，把表的行进行拆分。因为表的行数超过几百万行时，就会变慢，这时可以把一张的表的数据拆成多张表来存放。水平拆分，有许多策略，例如，取模分表，时间维度分表等。这种场景下，虽然我们根据特定规则分表了，我们仍然可以使用本地事务。

但是，库内分表，仅仅是解决了单表数据过大的问题，但并没有把单表的数据分散到不同的物理机上，因此并不能减轻 MySQL 服务器的压力，仍然存在同一个物理机上的资源竞争和瓶颈，包括 CPU、内存、磁盘 IO、网络带宽等。

对于分库拆分的场景，它把一张表的数据划分到不同的数据库，多个数据库的表结构一样。此时，如果我们根据一定规则将我们需要使用事务的数据路由到相同的库中，可以通过本地事务保证其强一致性。但是，对于按照业务和功能划分的垂直拆分，它将把业务数据分别放到不同的数据库中。这里，拆分后的系统就会遇到数据的一致性问题，因为我们需要通过事务保证的数据分散在不同的数据库中，而每个数据库只能保证自己的数据可以满足 ACID 保证强一致性，但是在分布式系统中，它们可能部署在不同的服务器上，只能通过网络进行通信，因此无法准确的知道其他数据库中的事务执行情况。

此外，不仅仅在跨库调用存在本地事务无法解决的问题，随着微服务的落地中，每个服务都有自己的数据库，并且数据库是相互独立且透明的。那如果服务 A 需要获取服务 B 的数据，就存在跨服务调用，如果遇到服务宕机，或者网络连接异常、同步调用超时等场景就会导致数据的不一致，这个也是一种分布式场景下需要考虑数据一致性问题。

总结一下，当业务量级扩大之后的分库，以及微服务落地之后的业务服务化，都会产生分布式数据不一致的问题。既然本地事务无法满足需求，因此分布式事务就要登上舞台。什么是分布式事务？我们可以简单地理解，它就是为了保证不同数据库的数据一致性的事务解决方案。这里，我们有必要先来了解下 CAP 原则和 BASE 理论。

CAP定理

CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性：

• 一致性(Consistency) ： 数据在多个副本之间是否能够保持一致的特性
• 可用性(Availability) ： 是指系统提供的服务必须一直处于可用状态，对于每一个用户的请求总是在有限的时间内返回结果，超过时间就认为系统是不可用的
• 分区容错性(Partition tolerance) ： 分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非整个网络环境都发生故障。

CAP定理的应用

• 放弃C(AP):这里说的放弃一致性，并不是完全不需要数据一致性，是指放弃数据的强一致性，保留数据的最终一致性。
• 放弃A(CP):其做法是一旦系统遇到网络分区或其他故障时，那受到影响的服务需要等待一定的时间，应用等待期间系统无法对外提供正常的服务，即不可用
• 放弃P(CA)：如果希望能够避免系统出现分区容错性问题，一种较为简单的做法就是将所有的数据(或者是与事物先相关的数据)都放在一个分布式节点上，这样虽然无法保证100%系统不会出错，但至少不会碰到由于网络分区带来的负面影响

BASE理论

在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？ 前人已经给我们提出来了另外一个理论，就是BASE理论，它是用来对CAP定理进行进一步扩充的。BASE理论指的是：

• 基本可用（Basically Available）：指分布式系统在出现故障时，允许损失部分的可用性来保证核心可用。
• 软状态（Soft State）：指允许分布式系统存在中间状态，该中间状态不会影响到系统的整体可用性。
• 最终一致性（Eventual Consistency）：指分布式系统中的所有副本数据经过一定时间后，最终能够达到一致的状态。

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

简单地理解，在分布式系统中，允许损失部分可用性，并且不同节点进行数据同步的过程存在延时，但是在经过一段时间的修复后，最终能够达到数据的最终一致性。BASE 强调的是数据的最终一致性。相比于 ACID 而言，BASE 通过允许损失部分一致性来获得可用性。

一致性模型

数据的一致性模型可以分成以下 3 类：

• 强一致性：数据更新成功后，任意时刻所有副本中的数据都是一致的，一般采用同步的方式实现。
• 弱一致性：数据更新成功后，系统不承诺立即可以读到最新写入的值，也不承诺具体多久之后可以读到。
• 最终一致性：弱一致性的一种形式，数据更新成功后，系统不承诺立即可以返回最新写入的值，但是保证最终会返回上一次更新操作的值。

分布式系统数据的强一致性、弱一致性和最终一致性可以通过Quorum NRW算法分析。

现在，业内比较常用的分布式事务解决方案，包括强一致性的两阶段提交协议，三阶段提交协议，以及最终一致性的可靠事件模式、补偿模式，阿里的 TCC 模式。

强一致性解决方案

二阶段提交协议

分布式系统的一个难点是如何保证架构下多个节点在进行事务性操作的时候保持一致性。为实现这个目的，二阶段提交算法的成立基于以下假设：

• 该分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。
• 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。
• 所有节点不会永久性损坏，即使损坏后仍然可以恢复。

第一阶段（投票阶段）

1. 协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。
2. 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）
3. 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。

第二阶段（提交执行阶段）

当协调者节点从所有参与者节点获得的相应消息都为”同意”时：

1. 协调者节点向所有参与者节点发出”正式提交(commit)“的请求。
2. 参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
3. 参与者节点向协调者节点发送”完成”消息。
4. 协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。

如果任一参与者节点在第一阶段返回的响应消息为”中止”，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：

1. 协调者节点向所有参与者节点发出”回滚操作(rollback)“的请求。
2. 参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
3. 参与者节点向协调者节点发送”回滚完成”消息。
4. 协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。

不管最后结果如何，第二阶段都会结束当前事务。

二阶段提交看起来确实能够提供原子性的操作，但是不幸的事，二阶段提交还是有几个缺点的：

• 效率低，与本地事务相比，XA协议的系统开销比较大（数据被锁定的时间跨度整个事务，直到全局事务的结束），只有支持XA协议的资源才能参与分布式事务。
• 2PC是反可伸缩模式的，在事务处理过程中，参与者需要一直持有资源直到整个事务的结束，这样当业务规模越来越大的情况下，它的局限性就越明显。
• 数据不一致，在2pc中的第二阶段时，当TM向RM发送提交请求之后，发生局部的网络异常或者在发送提交请求过程中TM发生故障， 这会导致只有一部分RM收到了提交请求，然后没有收到提交请求的RM不会执行事务的提交，于是整个分布式系统便会出现数据不一致。
• 单点故障， 由于TM的重要性，一旦发生故障，整个事务失效
• 参与者发生故障。协调者需要给每个参与者额外指定超时机制，超时后整个事务失败。（没有多少容错机制）
• 二阶段无法解决的问题：协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

为此，Dale Skeen和Michael Stonebraker在“A Formal Model of Crash Recovery in a Distributed System”中提出了三阶段提交协议（3PC）。

三阶段提交协议

三阶段提交协议 3PC

与两阶段提交不同的是，三阶段提交有两个改动点。

• 引入超时机制。同时在协调者和参与者中都引入超时机制。
• 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

CanCommit阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

1. 事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
2. 响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

PreCommit阶段

协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。 假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。

1. 发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。
2. 事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
3. 响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。

1. 发送中断请求 协调者向所有参与者发送abort请求。
2. 中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

doCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况。

**执行提交

1. 发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
2. 事务提交 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
3. 响应反馈 事务提交完之后，向协调者发送Ack响应。
4. 完成事务 协调者接收到所有参与者的ack响应之后，完成事务。

协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。

1. 发送中断请求 协调者向所有参与者发送abort请求
2. 事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
3. 反馈结果 参与者完成事务回滚之后，向协调者发送ACK消息
4. 中断事务 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

一文讲透微服务架构下如何保证事务的一致性

最终一致性解决方案

TCC 模式

二阶段提交协议和三阶段提交协议很好的解决了分布式事务的问题，但是在极端情况下仍然存在数据的不一致性，此外它对系统的开销会比较大，引入事务管理者（协调者）后，比较容易出现单点瓶颈，以及在业务规模不断变大的情况下，系统可伸缩性也会存在问题。注意的是，它是同步操作，因此引入事务后，直到全局事务结束才能释放资源，性能可能是一个很大的问题。因此，在高并发场景下很少使用。因此，阿里提出了另外一种解决方案：TCC 模式。注意的是，很多读者把二阶段提交等同于二阶段提交协议，这个是一个误区，事实上，TCC 模式也是一种二阶段提交。

TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作即回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。

成功情况：

失败情况：

TCC分为三个阶段：

1. Try 阶段是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的Confirm 一起才能真正构成一个完整的业务逻辑。
2. Confirm 阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用TCC则认为 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。
3. Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。

TM事务管理器
TM事务管理器可以实现为独立的服务，也可以让全局事务发起方充当TM的角色，TM独立出来是为了成为公用组件，是为了考虑系统结构和软件复用。

TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条，用来记录事务上下文，追踪和记录状态，由于Confirm 和cancel失败需进行重试，因此需要实现为幂等，幂等性是指同一个操作无论请求多少次，其结果都相同

TCC需要注意三种异常处理分别是空回滚、幂等、悬挂:

​ 空回滚：

​ 在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回滚，然后直接返回成功。

​ 出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。

​ 解决思路是关键就是要识别出这个空回滚。思路很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回滚；如果没执行，那就是空回滚。前面已经说过TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条。再额外增加一张分支事务记录表，其中有全局事务 ID 和分支事务 ID，第一阶段 Try 方法里会插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。

​ 幂等：

​ 通过前面介绍已经了解到，为了保证TCC二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段 Try、Confirm 和 Cancel 接口保证幂等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据不一致等严重问题。

​ 解决思路在上述“分支事务记录”中增加执行状态，每次执行前都查询该状态。

​ 悬挂：

​ 悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。

​ 出现原因是在 RPC 调用分支事务try时，先注册分支事务，再执行RPC调用，如果此时 RPC 调用的网络发生拥堵，通常 RPC 调用是有超时时间的，RPC 超时以后，TM就会通知RM回滚该分布式事务，可能回滚完成后，RPC 请求才到达参与者真正执行，而一个 Try 方法预留的业务资源，只有该分布式事务才能使用，该分布式事务第一阶段预留的业务资源就再也没有人能够处理了，对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。

​ 解决思路是如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，“分支事务记录”表中是否已经有二阶段事务记录，如果有则不执行Try。

案例分析，场景为 A 转账 30 元给 B，A和B账户在不同的服务。

方案1：

1
2
3
4
5
6
7
8
9

try：
    检查余额是否够30元
    扣减30元
    
confirm：
    空
​
cancel：
    增加30元

1
2
3
4
5
6
7
8

try：
    增加30元
​
confirm：
    空
​
cancel：
    减少30元

方案1说明：

1）账户A，这里的余额就是所谓的业务资源，按照前面提到的原则，在第一阶段需要检查并预留业务资源，因此，我们在扣钱 TCC 资源的 Try 接口里先检查 A 账户余额是否足够，如果足够则扣除 30 元。 Confirm 接口表示正式提交，由于业务资源已经在 Try 接口里扣除掉了，那么在第二阶段的 Confirm 接口里可以什么都不用做。Cancel 接口的执行表示整个事务回滚，账户A回滚则需要把 Try 接口里扣除掉的 30 元还给账户。

2）账号B，在第一阶段 Try 接口里实现给账户B加钱，Cancel 接口的执行表示整个事务回滚，账户B回滚则需要把 Try 接口里加的 30 元再减去。

方案1的问题分析：

1）如果账户A的try没有执行，直接cancel则就多加了30元。

2）由于try，cancel、confirm都是由单独的线程去调用，且会出现重复调用，所以都需要实现幂等。

3）账号B在try中增加30元，当try执行完成后可能会其它线程给消费了。

4）如果账户B的try没有执行在cancel则就多减了30元。

问题解决：

1）账户A的cancel方法需要判断try方法是否执行，正常执行try后方可执行cancel。

2）try，cancel、confirm方法实现幂等。

3）账号B在try方法中不允许更新账户金额，在confirm中更新账户金额。

4）账户B的cancel方法需要判断try方法是否执行，正常执行try后方可执行cancel。

优化方案：

1
2
3
4
5
6
7
8
9
10
11
12
13

try：
    try幂等校验
    try悬挂处理
    检查余额是否够30元
    扣减30元
​
confirm：
    空
​
cancel：
    cancel幂等校验
    cancel空回滚处理
    增加可用余额30元

1
2
3
4
5
6
7

try：
    空
confirm：
    confirm幂等校验
    正式增加30元
cancel：
    空 

上节，我们提到了重试机制。事实上，它也是一种最终一致性的解决方案：我们需要通过最大努力不断重试，保证数据库的操作最终一定可以保证数据一致性，如果最终多次重试失败可以根据相关日志并主动通知开发人员进行手工介入。注意的是，被调用方需要保证其幂等性。重试机制可以是同步机制，例如主业务服务调用超时或者非异常的调用失败需要及时重新发起业务调用。重试机制可以大致分为固定次数的重试策略与固定时间的重试策略。除此之外，我们还可以借助消息队列和定时任务机制。消息队列的重试机制，即消息消费失败则进行重新投递，这样就可以避免消息没有被消费而被丢弃，例如 RocketMQ 可以默认允许每条消息最多重试 16 次，每次重试的间隔时间可以进行设置。定时任务的重试机制，我们可以创建一张任务执行表，并增加一个“重试次数”字段。这种设计方案中，我们可以在定时调用时，获取这个任务是否是执行失败的状态并且没有超过重试次数，如果是则进行失败重试。但是，当出现执行失败的状态并且超过重试次数时，就说明这个任务永久失败了，需要开发人员进行手工介入与排查问题。

除了重试机制之外，也可以在每次更新的时候进行修复。例如，对于社交互动的点赞数、收藏数、评论数等计数场景，也许因为网络抖动或者相关服务不可用，导致某段时间内的数据不一致，我们就可以在每次更新的时候进行修复，保证系统经过一段较短的时间的自我恢复和修正，数据最终达到一致。需要注意的是，使用这种解决方案的情况下，如果某条数据出现不一致性，但是又没有再次更新修复，那么其永远都会是异常数据。

定时校对也是一种非常重要的解决手段，它采取周期性的进行校验操作来保证。关于定时任务框架的选型上，业内比较常用的有单机场景下的 Quartz，以及分布式场景下 Elastic-Job、XXL-JOB、SchedulerX 等分布式定时任务中间件。关于定时校对可以分为两种场景，一种是未完成的定时重试，例如我们利用定时任务扫描还未完成的调用任务，并通过补偿机制来修复，实现数据最终达到一致。另一种是定时核对，它需要主业务服务提供相关查询接口给从业务服务核对查询，用于恢复丢失的业务数据。现在，我们来试想一下电商场景的退款业务。在这个退款业务中会存在一个退款基础服务和自动化退款服务。此时，自动化退款服务在退款基础服务的基础上实现退款能力的增强，实现基于多规则的自动化退款，并且通过消息队列接收到退款基础服务推送的退款快照信息。但是，由于退款基础服务发送消息丢失或者消息队列在多次失败重试后的主动丢弃，都很有可能造成数据的不一致性。因此，我们通过定时从退款基础服务查询核对，恢复丢失的业务数据就显得特别重要了。

可靠事件模式

在分布式系统中，消息队列在服务端的架构中的地位非常重要，主要解决异步处理、系统解耦、流量削峰等场景。多个系统之间如果同步通信很容易造成阻塞，同时会将这些系统会耦合在一起。因此，引入了消息队列，一方面解决了同步通信机制造成的阻塞，另一方面通过消息队列进行业务解耦。

一文讲透微服务架构下如何保证事务的一致性

可靠事件模式，通过引入可靠的消息队列，只要保证当前的可靠事件投递并且消息队列确保事件传递至少一次，那么订阅这个事件的消费者保证事件能够在自己的业务内被消费即可。这里，请读者思考，是否只要引入了消息队列就可以解决问题了呢？事实上，只是引入消息队列并不能保证其最终的一致性，因为分布式部署环境下都是基于网络进行通信，而网络通信过程中，上下游可能因为各种原因而导致消息丢失。

其一，主业务服务发送消息时可能因为消息队列无法使用而发生失败。对于这种情况，我们可以让主业务服务（生产者）发送消息，再进行业务调用来确保。一般的做法是，主业务服务将要发送的消息持久化到本地数据库，设置标志状态为“待发送”状态，然后把消息发送给消息队列，消息队列收到消息后，也把消息持久化到其存储服务中，但并不是立即向从业务服务（消费者）投递消息，而是先向主业务服务（生产者）返回消息队列的响应结果，然后主业务服务判断响应结果执行之后的业务处理。如果响应失败，则放弃之后的业务处理，设置本地的持久化消息标志状态为“结束”状态。否则，执行后续的业务处理，设置本地的持久化消息标志状态为“已发送”状态。

1
2
3
4
5
6
7
8

public void doServer(){
    // 发送消息
    send();
    // 执行业务
    exec();
    // 更新消息状态
    updateMsg();
}

此外，消息队列发生消息后，也可能从业务服务（消费者）宕机而无法消费。绝大多数消息中间件对于这种情况，例如 RabbitMQ、RocketMQ 等引入了 ACK 机制。注意的是，默认的情况下，采用自动应答，这种方式中消息队列会发送消息后立即从消息队列中删除该消息。所以，为了确保消息的可靠投递，我们通过手动 ACK 方式，如果从业务服务（消费者）因宕机等原因没有发送 ACK，消息队列会将消息重新发送，保证消息的可靠性。从业务服务处理完相关业务后通过手动 ACK 通知消息队列，消息队列才从消息队列中删除该持久化消息。那么，消息队列如果一直重试失败而无法投递，就会出现消息主动丢弃的情况，我们需要如何解决呢？聪明的读者可能已经发现，我们在上个步骤中，主业务服务已经将要发送的消息持久化到本地数据库。因此，从业务服务消费成功后，它也会向消息队列发送一个通知消息，此时它是一个消息的生产者。主业务服务（消费者）接收到消息后，最终把本地的持久化消息标志状态为“完成”状态。说到这里，读者应该可以理解到我们使用“正反向消息机制”确保了消息队列可靠事件投递。当然，补偿机制也是必不可少的。定时任务会从数据库扫描在一定时间内未完成的消息并重新投递。

一文讲透微服务架构下如何保证事务的一致性

注意的是，因为从业务服务可能收到消息处理超时或者服务宕机，以及网络等原因导致而消息队列收不到消息的处理结果，因此可靠事件投递并且消息队列确保事件传递至少一次。这里，从业务服务（消费者）需要保证幂等性。如果从业务服务（消费者）没有保证接口的幂等性，将会导致重复提交等异常场景。此外，我们也可以独立消息服务，将消息服务独立部署，根据不同的业务场景共用该消息服务，降低重复开发服务的成本。

了解了“可靠事件模式”的方法论后，现在我们来看一个真实的案例来加深理解。首先，当用户发起退款后，自动化退款服务会收到一个退款的事件消息，此时，如果这笔退款符合自动化退款策略的话，自动化退款服务会先写入本地数据库持久化这笔退款快照，紧接着，发送一条执行退款的消息投递到给消息队列，消息队列接受到消息后返回响应成功结果，那么自动化退款服务就可以执行后续的业务逻辑。与此同时，消息队列异步地把消息投递给退款基础服务，然后退款基础服务执行自己业务相关的逻辑，执行失败与否由退款基础服务自我保证，如果执行成功则发送一条执行退款成功消息投递到给消息队列。最后，定时任务会从数据库扫描在一定时间内未完成的消息并重新投递。这里，需要注意的是，自动化退款服务持久化的退款快照可以理解为需要确保投递成功的消息，由“正反向消息机制”和“定时任务”确保其成功投递。此外，真正的退款出账逻辑在退款基础服务来保证，因此它要保证幂等性，及出账逻辑的收敛。当出现执行失败的状态并且超过重试次数时，就说明这个任务永久失败了，需要开发人员进行手工介入与排查问题。

一文讲透微服务架构下如何保证事务的一致性

总结一下，引入了消息队列并不能保证可靠事件投递，换句话说，由于网络等各种原因而导致消息丢失不能保证其最终的一致性，因此，我们需要通过“正反向消息机制”确保了消息队列可靠事件投递，并且使用补偿机制尽可能在一定时间内未完成的消息并重新投递。

开源项目的分布式事务实现解读

开源项目中对分布式事务的应用有很多值得我们学习与借鉴的地方。本节，我们就来对其实现进行解读。

RocketMQ

Apache RocketMQ 是阿里开源的一款高性能、高吞吐量的分布式消息中间件。在历年双 11 中，RocketMQ 都承担了阿里巴巴生产系统全部的消息流转，在核心交易链路有着稳定和出色的表现，是承载交易峰值的核心基础产品之一。RocketMQ 同时存在商用版 MQ，阿里巴巴对于开源版本和商业版本，主要区别在于：会开源分布式消息所有核心的特性，而在商业层面，尤其是云平台的搭建上面，将运维管控、安全授权、深度培训等纳入商业重中之重。

Apache RocketMQ 4.3 版本正式支持分布式事务消息。RocketMQ 事务消息设计主要解决了生产者端的消息发送与本地事务执行的原子性问题，换句话说，如果本地事务执行不成功，则不会进行 MQ 消息推送。那么，聪明的你可能就会存在疑问：我们可以先执行本地事务，执行成功了再发送 MQ 消息，这样不就可以保证事务性的？但是，请你再认真的思考下，如果 MQ 消息发送不成功怎么办呢？事实上，RocketMQ 对此提供一个很好的思路和解决方案。
RocketMQ 首先会发送预执行消息到 MQ，并且在发送预执行消息成功后执行本地事务。紧接着，它根据本地事务执行结果进行后续执行逻辑，如果本地事务执行结果是 commit，那么正式投递 MQ 消息，如果本地事务执行结果是 rollback，则 MQ 删除之前投递的预执行消息，不进行投递下发。注意的是，对于异常情况，例如执行本地事务过程中，服务器宕机或者超时，RocketMQ 将会不停的询问其同组的其他生产者端来获取状态。

一文讲透微服务架构下如何保证事务的一致性

ServiceComb

ServiceComb 基于华为内部的 CSE(Cloud Service Engine) 框架开源而来，它提供了一套包含代码框架生成，服务注册发现，负载均衡，服务可靠性（容错熔断，限流降级，调用链追踪）等功能的微服务框架。其中，ServiceComb Saga 是一个微服务应用的数据最终一致性解决方案。

Saga 拆分分布式事务为多个本地事务，然后由 Saga 引擎负责协调。如果整个流程正常结束，那么业务成功完成；如果在这过程中实现出现部分失败，那么 Saga 引擎调用补偿操作。Saga 有两种恢复的策略 ：向前恢复和向后恢复。其中，向前恢复对失败的节点采取最大努力不断重试，保证数据库的操作最终一定可以保证数据一致性，如果最终多次重试失败可以根据相关日志并主动通知开发人员进行手工介入。向后恢复对之前所有成功的节点执行回滚的事务操作，这样保证数据达到一致的效果。

Saga 与 TCC 不同之处在于，Saga 比 TCC 少了一个 Try 操作。因此，Saga 会直接提交到数据库，然后出现失败的时候，进行补偿操作。Saga 的设计可能导致在极端场景下的补偿动作比较麻烦，但是对于简单的业务逻辑侵入性更低，更轻量级，并且减少了通信次数。

一文讲透微服务架构下如何保证事务的一致性

ServiceComb Saga 在其理论基础上进行了扩展，它包含两个组件： alpha 和 omega。alpha 充当协调者，主要负责对事务的事件进行持久化存储以及协调子事务的状态，使其得以最终与全局事务的状态保持一致。omega 是微服务中内嵌的一个 agent，负责对网络请求进行拦截并向 alpha 上报事务事件，并在异常情况下根据 alpha 下发的指令执行相应的补偿操作。在预处理阶段，alpha 会记录事务开始的事件；在后处理阶段，alpha 会记录事务结束的事件。因此，每个成功的子事务都有一一对应的开始及结束事件。在服务生产方，omega 会拦截请求中事务相关的 id 来提取事务的上下文。在服务消费方，omega 会在请求中注入事务相关的 id 来传递事务的上下文。通过服务提供方和服务消费方的这种协作处理，子事务能连接起来形成一个完整的全局事务。注意的是，Saga 要求相关的子事务提供事务处理方法，并且提供补偿函数。这里，添加 @EnableOmega 的注解来初始化 omega 的配置并与 alpha 建立连接。在全局事务的起点添加 @SagaStart 的注解，在子事务添加 @Compensable 的注解指明其对应的补偿方法。

使用案例： https://github.com/apache/servicecomb-saga/tree/master/saga-demo

1
2
3
4
5
6
7
8
9
10
11
12
13

@EnableOmega
public class Application{
  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }
}
 
@SagaStart
public void xxx() { }
 
 
@Compensable
public void transfer() { }

现在，我们来看一下它的业务流程图。

一文讲透微服务架构下如何保证事务的一致性

References