分布式系统事务一致性解决方案
开篇
在OLTP系统领域，我们在很多业务场景下都会面临事务一致性方面的需求，例如最经典的Bob给Smith转账的案例。传统的企业开发，系统往往是以单体应用形式存在的，也没有横跨多个数据库。我们通常只需借助开发平台中特有数据访问技术和框架（例如Spring、JDBC、ADO.NET），结合关系型数据库自带的事务管理机制来实现事务性的需求。关系型数据库通常具有ACID特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
而大型互联网平台往往是由一系列分布式系统构成的，开发语言平台和技术栈也相对比较杂，尤其是在SOA和微服务架构盛行的今天，一个看起来简单的功能，内部可能需要调用多个“服务”并操作多个数据库或分片来实现，情况往往会复杂很多。单一的技术手段和解决方案，已经无法应对和满足这些复杂的场景了
分布式系统的特性
对分布式系统有过研究的读者，可能听说过“CAP定律”、“Base理论”等，非常巧的是，化学理论中ACID是酸、Base恰好是碱。这里笔者不对这些概念做过多的解释，有兴趣的读者可以查看相关参考资料。CAP定律如下：
在分布式系统中，同时满足“CAP定律”中的“一致性”、“可用性”和“分区容错性”三者是不可能的，这比现实中找对象需同时满足“高、富、帅”或“白、富、美”更加困难。在互联网领域的绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。
分布式事务
提到分布式系统，必然要提到分布式事务。要想理解分布式事务，不得不先介绍一下两阶段提交协议和三阶段提交协议
2PC
2PC，二阶段提交协议，即将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。事务的发起者称协调者，事务的执行者称参与者。
阶段1：准备阶段
1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
2、各参与者执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。
3、如参与者执行成功，给协调者反馈YES，即可以提交；如执行失败，给协调者反馈NO，即不可提交。
阶段2：提交阶段
此阶段分两种情况：所有参与者均反馈YES、或任何一个参与者反馈NO。
所有参与者均反馈YES时，即提交事务。
任何一个参与者反馈NO时，即中断事务。
提交事务：（所有参与者均反馈YES）
1、协调者向所有参与者发出正式提交事务的请求（即Commit请求）。
2、参与者执行Commit请求，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。
附如下示意图：
中断事务：（任何一个参与者反馈NO）
1、协调者向所有参与者发出回滚请求（即Rollback请求）。
2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。
2PC的缺陷
1、同步阻塞：最大的问题即同步阻塞，即：所有参与事务的逻辑均处于阻塞状态。
2、单点：协调者存在单点问题，如果协调者出现故障，参与者将一直处于锁定状态。
3、脑裂：在阶段2中，如果只有部分参与者接收并执行了Commit请求，会导致节点数据不一致。
由于2PC存在如上同步阻塞、单点、脑裂问题，因此又出现了2PC的改进方案，即3PC。
3PC
3PC，三阶段提交协议，是2PC的改进版本，即将事务的提交过程分为CanCommit、PreCommit、do Commit三个阶段来进行处理
阶段1：CanCommit
1、协调者向所有参与者发出包含事务内容的CanCommit请求，询问是否可以提交事务，并等待所有参与者答复。
2、参与者收到CanCommit请求后，如果认为可以执行事务操作，则反馈YES并进入预备状态，否则反馈NO。
阶段2：PreCommit
此阶段分两种情况：
1、所有参与者均反馈YES，即执行事务预提交。
2、任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。
事务预提交：（所有参与者均反馈YES时）
1、协调者向所有参与者发出PreCommit请求，进入准备阶段。
2、参与者收到PreCommit请求后，执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。
3、各参与者向协调者反馈Ack响应或No响应，并等待最终指令。
中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）
1、协调者向所有参与者发出abort请求。
2、无论收到协调者发出的abort请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。
阶段3：do Commit
此阶段也存在两种情况：
1、所有参与者均反馈Ack响应，即执行真正的事务提交。
2、任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。
提交事务：（所有参与者均反馈Ack响应时）
1、如果协调者处于工作状态，则向所有参与者发出do Commit请求。
2、参与者收到do Commit请求后，会正式执行事务提交，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。
中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）
1、如果协调者处于工作状态，向所有参与者发出abort请求。
2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。
注意：进入阶段三后，无论协调者出现问题，或者协调者与参与者网络出现问题，都会导致参与者无法接收到协调者发出的do Commit请求或abort请求。此时，参与者都会在等待超时之后，继续执行事务提交。
优点：降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段3中协调者出现问题时，参与者会继续提交事务。
缺陷：脑裂问题依然存在，即在参与者收到PreCommit请求后等待最终指令，如果此时协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
提供回滚接口
在服务化架构中，功能X，需要去协调后端的A、B甚至更多的原子服务。那么问题来了，假如A和B其中一个调用失败了，那可怎么办呢？
在笔者的工作中经常遇到这类问题，往往提供了一个BFF层来协调调用A、B服务。如果有些是需要同步返回结果的，我会尽量按照“串行”的方式去调用。如果调用A失败，则不会盲目去调用B。如果调用A成功，而调用B失败，会尝试去回滚刚刚对A的调用操作。
当然，有些时候我们不必严格提供单独对应的回滚接口，可以通过传递参数巧妙的实现。
这样的情况，我们会尽量把可提供回滚接口的服务放在前面。举个例子说明：
我们的某个论坛网站，每天登录成功后会奖励用户5个积分，但是积分和用户又是两套独立的子系统服务，对应不同的DB，这控制起来就比较麻烦了。解决思路：
- 把登录和加积分的服务调用放在BFF层一个本地方法中。
- 当用户请求登录接口时，先执行加积分操作，加分成功后再执行登录操作
- 如果登录成功，那当然最好了，积分也加成功了。如果登录失败，则调用加积分对应的回滚接口（执行减积分的操作）。
总结：这种方式缺点比较多，通常在复杂场景下是不推荐使用的，除非是非常简单的场景，非常容易提供回滚，而且依赖的服务也非常少的情况。
这种实现方式会造成代码量庞大，耦合性高。而且非常有局限性，因为有很多的业务是无法很简单的实现回滚的，如果串行的服务很多，回滚的成本实在太高。
本地消息表
这种实现方式的思路，其实是源于ebay，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。如果不考虑性能及设计优雅，借助关系型数据库中的表即可实现。
举个经典的跨行转账的例子来描述。
第一步伪代码如下，扣款1W，通过本地事务保证了凭证消息插入到消息表中。
第二步通知对方银行账户上加1W了。那问题来了，如何通知到对方呢？
通常采用两种方式：
- 采用时效性高的MQ，由对方订阅消息并监听，有消息时自动触发事件
- 采用定时轮询扫描的方式，去检查消息表的数据。
两种方式其实各有利弊，仅仅依靠MQ，可能会出现通知失败的问题。而过于频繁的定时轮询，效率也不是最佳的（90%是无用功）。所以，我们一般会把两种方式结合起来使用。
解决了通知的问题，又有新的问题了。万一这消息有重复被消费，往用户帐号上多加了钱，那岂不是后果很严重？
仔细思考，其实我们可以消息消费方，也通过一个“消费状态表”来记录消费状态。在执行“加款”操作之前，检测下该消息（提供标识）是否已经消费过，消费完成后，通过本地事务控制来更新这个“消费状态表”。这样子就避免重复消费的问题。
总结：上诉的方式是一种非常经典的实现，基本避免了分布式事务，实现了“最终一致性”。但是，关系型数据库的吞吐量和性能方面存在瓶颈，频繁的读写消息会给数据库造成压力。所以，在真正的高并发场景下，该方案也会有瓶颈和限制的。
MQ（非事务消息）
通常情况下，在使用非事务消息支持的MQ产品时，我们很难将业务操作与对MQ的操作放在一个本地事务域中管理。通俗点描述，还是以上述提到的“跨行转账”为例，我们很难保证在扣款完成之后对MQ投递消息的操作就一定能成功。这样一致性似乎很难保证。
先从消息生产者这端来分析，请看伪代码：
根据上述代码及注释，我们来分析下可能的情况：
- 操作数据库成功，向MQ中投递消息也成功，皆大欢喜
- 操作数据库失败，不会向MQ中投递消息了
- 操作数据库成功，但是向MQ中投递消息时失败，向外抛出了异常，刚刚执行的更新数据库的操作将被回滚
从上面分析的几种情况来看，貌似问题都不大的。那么我们来分析下消费者端面临的问题：
- 消息出列后，消费者对应的业务操作要执行成功。如果业务执行失败，消息不能失效或者丢失。需要保证消息与业务操作一致
- 尽量避免消息重复消费。如果重复消费，也不能因此影响业务结果
如何保证消息与业务操作一致，不丢失？
主流的MQ产品都具有持久化消息的功能。如果消费者宕机或者消费失败，都可以执行重试机制的（有些MQ可以自定义重试次数）。
如何避免消息被重复消费造成的问题？
- 保证消费者调用业务的服务接口的幂等性
- 通过消费日志或者类似状态表来记录消费状态，便于判断（建议在业务上自行实现，而不依赖MQ产品提供该特性）
总结：这种方式比较常见，性能和吞吐量是优于使用关系型数据库消息表的方案。如果MQ自身和业务都具有高可用性，理论上是可以满足大部分的业务场景的。不过在没有充分测试的情况下，不建议在交易业务中直接使用。
MQ（事务消息）
举个例子，Bob向Smith转账，那我们到底是先发送消息，还是先执行扣款操作？
好像都可能会出问题。如果先发消息，扣款操作失败，那么Smith的账户里面会多出一笔钱。反过来，如果先执行扣款操作，后发送消息，那有可能扣款成功了但是消息没发出去，Smith收不到钱。除了上面介绍的通过异常捕获和回滚的方式外，还有没有其他的思路呢？
下面以阿里巴巴的RocketMQ中间件为例，分析下其设计和实现思路。
RocketMQ第一阶段发送Prepared消息时，会拿到消息的地址，第二阶段执行本地事物，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。细心的读者可能又发现问题了，如果确认消息发送失败了怎么办？RocketMQ会定期扫描消息集群中的事物消息，这时候发现了Prepared消息，它会向消息发送者确认，Bob的钱到底是减了还是没减呢？如果减了是回滚还是继续发送确认消息呢？RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。如下图：
总结：据笔者的了解，各大知名的电商平台和互联网公司，几乎都是采用类似的设计思路来实现“最终一致性”的。这种方式适合的业务场景广泛，而且比较可靠。不过这种方式技术实现的难度比较大。目前主流的开源MQ（ActiveMQ、RabbitMQ、Kafka）均未实现对事务消息的支持，所以需二次开发或者新造轮子。比较遗憾的是，RocketMQ事务消息部分的代码也并未开源，需要自己去实现。
其他补偿方式
做过支付宝交易接口的同学都知道，我们一般会在支付宝的回调页面和接口里，解密参数，然后调用系统中更新交易状态相关的服务，将订单更新为付款成功。同时，只有当我们回调页面中输出了success字样或者标识业务处理成功相应状态码时，支付宝才会停止回调请求。否则，支付宝会每间隔一段时间后，再向客户方发起回调请求，直到输出成功标识为止。
其实这就是一个很典型的补偿例子，跟一些MQ重试补偿机制很类似。
一般成熟的系统中，对于级别较高的服务和接口，整体的可用性通常都会很高。如果有些业务由于瞬时的网络故障或调用超时等问题，那么这种重试机制其实是非常有效的。
当然，考虑个比较极端的场景，假如系统自身有bug或者程序逻辑有问题，那么重试1W次那也是无济于事的。那岂不是就发生了“明明已经付款，却显示未付款不发货”类似的悲剧？
其实为了交易系统更可靠，我们一般会在类似交易这种高级别的服务代码中，加入详细日志记录的，一旦系统内部引发类似致命异常，会有邮件通知。同时，后台会有定时任务扫描和分析此类日志，检查出这种特殊的情况，会尝试通过程序来补偿并邮件通知相关人员。
在某些特殊的情况下，还会有“人工补偿”的，这也是最后一道屏障。
接口同步调用模式与一致性解决方案
模式分析：A服务同步调用B服务的接口并等待结果返回，后续的流程会依赖B服务的返回结果。这种交互模式下，A服务得到的结果细分有三种情况。
- 请求发起阶段网络超时或异常，此时，B服务未收到请求，未作出相应的处理；
- 结果返回阶段网络超时或异常，此时，B服务已收到请求，并作出相应的处理；
- 正常结果返回（明确的成功或失败）。
业务场景：适用于大规模、高并发的短小操作且依赖返回值的场景。例如，交易服务和库存服务（卡券服务、红包服务等）的交互、用户登录和准入服务的交互等。
解决方案：方案一，服务调用方查询重试方案；方案二，TCC方案。
- 服务调用方查询重试方案，适合一个从业务服务场景。
1 下单减库存方法() { 2 // 1.准备操作 3 // 2.重试调用B服务 4 result = RetryUtil { 5 while(重试次数 < 最大重试次数) { 6 try { 7 if (重试次数 != 0) { 8 // case1：网络超时或异常（catch分支） 9 // case2：查询到扣减库存操作，result=成功（return） 10 // case3：查不到扣减库存操作，result=失败（继续下面操作） 11 result = rpc.查询扣减库存是否成功(); 12 if (result == 成功) { 13 return result; 14 } 15 } 16 // case1：网络超时或异常（catch分支） 17 // case2：扣减库存成功，result=成功（return） 18 // case3：扣减库存失败，result=失败（return） 19 return rpc.扣减库存(); 20 } catch (Exception e) { 21 if (重试次数 = 最大重试次数) { 22 // 报警，人工处理或者（近实时）对账系统自动校准 23 // 抛出异常，中断后续流程 24 throw 自定义异常; //或者result封装异常 25 } 26 } 27 } 28 }; 29 // 3.后续操作 30 }注：1) 查询重试后依然失败（极少），报警，人工处理或者准实时对账系统自动校准；
2) 重试次数不宜多，甚至只重试一次；
3) B服务处理请求要做幂等。
- TCC方案，适合多个从业务服务场景。TCC是阿里在二阶段提交协议的基础上提出的一种解决分布式事务一致性的协议，原理图如下。其对应的产品是DTX（老版是DTS）。DTS中有个快速开始的例子看明白了，TCC就基本OK了。在蚂蚁金服内部被广泛地应用于交易、转账、红包等核心资金链路，服务于亿级用户的资金操作。
注：关于TCC，个人认为，理解原理很重要。工作中遇到吻合的场景可以根据原理自行实现，满足业务即可。
接口异步调用模式与一致性解决方案
模式分析：A服务调用B服务，B服务先受理请求并落库，状态是待处理。B服务处理请求很耗时，或者要依赖其他的服务。B服务处理完后通知A服务或者A服务定时去查询B服务的处理结果。这种交互模式下，对于CASE-1，第1步和第2步同接口同步调用模式，第3步同消息异步处理模式；对于CASE-2，相当于两次接口同步调用模式。
业务场景：适用于非核心链路上负载较高的处理环节，这个环节经常耗时较长，并且对时效性要求不高。例如，用户提现时，账户系统和提现系统的交互（CASE-1）；提现系统和三方系统（银行系统或者三方托管系统）的交互（CASE-2）。
解决方案：服务被调方最大努力处理方案。由于B服务中请求有落库，所以可以用定时任务不断重试尽最大努力将请求处理出结果。处理后，将请求状态设置成对应的结果落库。然后再通知A服务或者A服务异步主动查询。
View Code注：1) B服务通常都是接受请求并持久化后才返回A服务受理成功。避免服务进程被杀掉而导致请求丢失。
2) 不管是第（1,2）两步还是CASE-2中的第（3,4）两步，如果查询重试失败，可以落库，用定时任务处理，知道成功。反正不像接口同步调用模式，A服务不需要实时的结果。
消息异步处理模式与一致性解决方案
模式分析：A服务将B服务需要的信息通过消息中间件传递给B服务，A服务无需知道B服务的处理结果。这种交互模式下，消息生产者要确保消息发送成功；消息消费者要确保消息消费成功。
业务场景：消息异步处理模式与接口异步调用模式类似，多应用于非核心链路上负载较高的处理环节中，井且服务的上游不关心下游的处理结果，下游也不需要向上游返回处理结果。例如，在电商系统中，用户下订单支付且交易成功后，发送消息给物流系统或者账务系统进行后续的处理。
解决方案：生产者最大努力通知+消费者最大努力处理方案。
- 非事务消息，生产者先执行本地事务并将消息落库，状态标记为待发送，然后发送消息。如果发送成功，则将消息改为发送成功。定时任务定时从数据库捞取在一定时间内待发送的消息并将消息发送。通过定时任务来保证消息的发送。为确保消息一定能消费，消费者一般采用手动ACK机制，那么消息服务器必然会重发未ACK的消息，这就要求消息消费者做好幂等。
View Code - 事务消息，以RocketMQ为例，下图是RocketMQ事务消息的流程。官网有示例代码。和不支持事务的消息中间相比，只是消息发送的时候，保证了和本地事务的一致。消费者实现还是不变。
注：1) 定时任务重试发送消息和消息服务器重发未ACK的消息一般都是时间阶梯式的（2n*时间间隔）；
2) 支持事务消息中间件之RocketMQ：https://rocketmq.apache.org/docs/quick-start。
保证操作幂等性的常用方法↑
- 有业务状态，业务逻辑来保证幂等。比如接到支付成功的消息订单状态变成支付完成，如果当前状态是支付完成，则再收到一个支付成功的消息则说明消息重复了，直接作为消息成功处理。
- 无业务状态，业务唯一ID保证幂等。增加一个去重表（或分布式缓存）来记录有业务唯一ID的操作。比如调用充值接口，当请求过来时，会根据唯一充值ID去查充值流水表，若已经存在，则直接返回；否则继续进行充值操作。
注：保证幂等性的方法很多，根据具体的业务场景，总能很容易找到保证幂等性的方法。
小结
上诉的几种方案中，笔者也大致总结了其设计思路，优势，劣势等，相信读者已经有了一定的理解。其实分布式系统的事务一致性本身是一个技术难题，目前没有一种很简单很完美的方案能够应对所有场景。具体还是要使用者根据不同的业务场景去抉择。
