说到分布式事务，就会谈到那个经典的”账号转账”问题：2个账号，分布处于2个不同的DB，A要扣钱，B要加钱，如何保证原子性？
传统方案 – 2PC
（1）2PC的理论层面：
2pc涉及到2个阶段，3个操作：
阶段1：“准备提交”。事务协调者向所有参与者发起prepare，所有参与者回答yes/no。
阶段2：“正式提交”。如果所有参与者都回答yes，则向所有参与者发起commit；否则，向所有参与者发起rollback。
因此，要实现2pc，所有参与者，都得实现3个接口：prepare/commit/rollback。
（2）2PC的实现层面
对应的实现层面，也就是XA协议，通常的数据库都实现了这个协议。
有一个Atomikos开源库，提供了2PC的实现方案。有兴趣的可以去看一下如何使用。
（3）2PC的问题
问题1：阶段2，事务协调者挂了，则所有参与者接受不到commit/rollback指令，将处于“悬而不决”状态
问题2：阶段2，其中一个参与者超时或者出错，那其他参与者，是commit，还是rollback呢？ 也不能确定
为了解决2pc的问题，又引入3pc。3pc有类似的挂了如何解决的问题，因此还是没能彻底解决问题，此处就不详述了。
问题3：2PC的实现，目前主要是用在数据库层面（数据库实现了XA协议）。但目前，大家基本都是微服务架构，不会直接在2个业务DB之间搞一致性，而是想如何在2个服务上面实现一致性。
正因为2PC有上面诸多问题和不便，实践中一般很少使用，而是采用下面将要讲的各种方案。
最终一致性
一般的思路都是通过消息中间件来实现“最终一致性”：A系统扣钱，然后发条消息给中间件，B系统接收此消息，进行加钱。
但这里面有个问题：A是先update DB，后发送消息呢？ 还是先发送消息，后update DB？
假设先update DB成功，发送消息网络失败，重发又失败，怎么办？
假设先发送消息成功，update DB失败。消息已经发出去了，又不能撤回，怎么办？
所以，这里下个结论： 只要发送消息和update DB这2个操作不是原子的，无论谁先谁后，都是有问题的。
那这个问题怎么解决呢？？
错误的方案0
有人可能想到了，我可以把“发送消息”这个网络调用和update DB放在同1个事务里面，如果发送消息失败，update DB自动回滚。这样不就保证2个操作的原子性了吗？
这个方案看似正确，其实是错误的，原因有2：
（1）网络的2将军问题：发送消息失败，发送方并不知道是消息中间件真的没有收到消息呢？还是消息已经收到了，只是返回response的时候失败了？
如果是已经收到消息了，而发送端认为没有收到，执行update db的回滚操作。则会导致A账号的钱没有扣，B账号的钱却加了。
（2）把网络调用放在DB事务里面，可能会因为网络的延时，导致DB长事务。严重的，会block整个DB。这个风险很大。
基于以上分析，我们知道，这个方案其实是错误的！
方案1 – 最终一致性（业务方自己实现）
假设消息中间件没有提供“事务消息”功能，比如你用的是Kafka。那如何解决这个问题呢？
解决方案如下：
（1）Producer端准备1张消息表，把update DB和insert message这2个操作，放在一个DB事务里面。
（2）准备一个后台程序，源源不断的把消息表中的message传送给消息中间件。失败了，不断重试重传。允许消息重复，但消息不会丢，顺序也不会打乱。
（3）Consumer端准备一个判重表。处理过的消息，记在判重表里面。实现业务的幂等。但这里又涉及一个原子性问题：如果保证消息消费 + insert message到判重表这2个操作的原子性？
消费成功，但insert判重表失败，怎么办？关于这个，在Kafka的源码分析系列，第1篇， exactly once问题的时候，有过讨论。
通过上面3步，我们基本就解决了这里update db和发送网络消息这2个操作的原子性问题。
但这个方案的一个缺点就是：需要设计DB消息表，同时还需要一个后台任务，不断扫描本地消息。导致消息的处理和业务逻辑耦合额外增加业务方的负担。
方案2 – 最终一致性（RocketMQ 事务消息）
为了能解决该问题，同时又不和业务耦合，RocketMQ提出了“事务消息”的概念。
具体来说，就是把消息的发送分成了2个阶段：Prepare阶段和确认阶段。
具体来说，上面的2个步骤，被分解成3个步骤：
(1) 发送Prepared消息
(2) update DB
(3) 根据update DB结果成功或失败，Confirm或者取消Prepared消息。
可能有人会问了，前2步执行成功了，最后1步失败了怎么办？这里就涉及到了RocketMQ的关键点：RocketMQ会定期（默认是1分钟）扫描所有的Prepared消息，询问发送方，到底是要确认这条消息发出去？还是取消此条消息？
总结：对比方案2和方案1，RocketMQ最大的改变，其实就是把“扫描消息表”这个事情，不让业务方做，而是消息中间件帮着做了。
至于消息表，其实还是没有省掉。因为消息中间件要询问发送方，事物是否执行成功，还是需要一个“变相的本地消息表”，记录事物执行状态。
人工介入
可能有人又要说了，无论方案1，还是方案2，发送端把消息成功放入了队列，但消费端消费失败怎么办？
消费失败了，重试，还一直失败怎么办？是不是要自动回滚整个流程？
答案是人工介入。从工程实践角度讲，这种整个流程自动回滚的代价是非常巨大的，不但实现复杂，还会引入新的问题。比如自动回滚失败，又怎么处理？
对应这种极低概率的case，采取人工处理，会比实现一个高复杂的自动化回滚系统，更加可靠，也更加简单。
方案3：TCC
为了解决SOA系统中的分布式事务问题，支付宝提出了TCC。2PC通常都是在跨库的DB层面，而TCC本质就是一个应用层面的2PC。
同样，TCC中，每个参与者需要3个操作：Try/Confirm/Cancel，也是2个阶段。
阶段1：”资源预留/资源检查“，也就是事务协调者调用所有参与者的Try操作
阶段2：“一起提交”。如果所有的Try成功，一起执行Confirm。否则，所有的执行Cancel.
TCC是如何解决2PC的问题呢？
关键：Try阶段成功之后，Confirm如果失败(不管是协调者挂了，还是某个参与者超时），不断重试！！
同样，Cancel失败了，也是不断重试。这就要求Confirm/Cancel都必须是幂等操作。
下面以1个转账case为例，来说明TCC的过程：
有3个账号A, B, C，通过SOA提供的转账服务操作。A, B同时分别要向C转30, 50元，最后C的账号+80，A, B各减30, 50。
阶段1：A账号锁定30，B账号锁定50，检查C账号的合法性（比如C账号是否违法被冻结，C账号是否已注销。。。）。
所以，对应的“扣钱”的Try操作就是”锁定”，对应的“加钱”的Try操作就是检查账号合法性
阶段2：A, B, C都Try成功，执行Confirm。即A, B减钱，C加钱。如果任意一个失败，不断重试！
从上面的案例可以看出，Try操作主要是为了“保证业务操作的前置条件都得到满足”，然后在Confirm阶段，因为前置条件都满足了，所以可以不断重试保证成功。
上面说的“最终一致性”和TCC都是比较“完美”的方案，能完全保证数据的一致性。但是呢，最终一致性这个方案是异步的，TCC呢，需要2个阶段，性能损耗大。
如果我需要1个同步的方案，可以立马得到结果，同时又要有很高的性能，支持高并发，那怎么处理呢？
方案4：妥协方案 – 弱一致性 + 基于状态的补偿
举个典型场景：
电商网站的下单，扣库存。订单系统有订单的DB，订单的服务；库存系统有库存的DB，库存的服务。 如何保证下单 + 扣库存，2个的原子性呢？
如果用上面的最终一致性方案，因为是异步的，库存扣减不及时，会导致超卖，因此最终一致性的方案不可行；
如果用TCC的方案，性能可能又达不到。
这里，就采用了一种弱一致的方案，什么意思呢？
对于该需求，有1个关键特性：对于电商的购物来讲，允许少卖，但不能超卖。你有100件东西，卖给99个人，有1件没有卖出去，这个可以接受；但是卖给了101个人，其中1个人拿不到货，平台违约，这个就不能接受。
而该处就利用了这个特性，具体是这么做的：
先扣库存，再提交订单。
（1）扣库存失败，不提交订单了，直接返回失败，调用方重试（此处可能会多扣库存）
（2）扣库存成功，提交订单失败，返回失败，调用方重试（此处可能会多扣库存）
（3）扣库存成功，提交订单成功，返回成功。
反过来，你先提交订单，后扣库存，也是按照类似的这个思路。
最终，只要保证1点：库存可以多扣，不能少扣！！！
但是，库存多扣了，这个数据不一致，怎么补偿呢？
库存每扣1次，都会生成1条流水记录。这条记录的初始状态是“占用”，等订单支付成功之后，会把状态改成“释放”。
对于那些过了很长时间，一直是占用，而不释放的库存。要么是因为前面多扣造成的，要么是因为用户下了单，但不支付。
通过比对，库存系统的“占用又没有释放的库存流水“与订单系统的未支付的订单，我们就可以回收掉这些库存，同时把对应的订单取消掉。（就类似12306网站一样，过多长时间，你不支付，订单就取消了，库存释放）
方案5： 妥协方案 – 重试 + 回滚 + 监控报警 + 人工修复
对于方案4，我们是基于订单的状态 + 库存流水的状态，做补偿（或者说叫对账）。
如果业务很复杂，状态的维护也很复杂。方案5呢，就是1种更加妥协而简单的办法。
提交订单不是失败了嘛！
先重试！
重试还不成功，回滚库存的扣减！
回滚也失败，发报警出来，人工干预修复！
总之，根据业务逻辑，通过重试3次，或者回滚的办法，尽最大限度，保证一致。实在不一致，就发报警，让人工干预。只要日志流水记录的完整，人工肯定可以修复！ （通常只要业务逻辑本身没问题，重试、回滚之后，还失败的概率会比较低，所以这种办法虽然丑陋，但蛮实用）
后话
其他的，诸如状态机驱动、1PC之类的办法，只是说法不一，个人认为本质上都是方案4/方案5的做法。
总结
在上文中，总结了实践中比较靠谱的5种方法：2种最终一致性的方案，2种妥协办法，TCC。
实现层面，妥协的办法肯定最容易，TCC最复杂。
有兴趣朋友也可以进一步关注公众号“架构之道与术”，更加深入的讨论此问题。
或扫描如下二维码：
