分布式事务--补偿模式+Mq/TCC

阅读：【分布式事务】TCC补偿性方案
https://blog.csdn.net/hu_zhiting/article/details/77190272

补偿模式

MQ（事务消息） ：

举个例子，Bob向Smith转账，那我们到底是先发送消息，还是先执行扣款操作？

好像都可能会出问题。如果先发消息，扣款操作失败，那么Smith的账户里面会多出一笔钱。反过来，如果先执行扣款操作，后发送消息，那有可能扣款成功了但是消息没发出去，Smith收不到钱。除了上面介绍的通过异常捕获和回滚的方式外，还有没有其他的思路呢？

下面以阿里巴巴的RocketMQ中间件为例，分析下其设计和实现思路。

RocketMQ第一阶段发送Prepared消息时，会拿到消息的地址，第二阶段执行本地事物，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。细心的读者可能又发现问题了，如果确认消息发送失败了怎么办？RocketMQ会定期扫描消息集群中的事物消息，这时候发现了Prepared消息，它会向消息发送者确认，Bob的钱到底是减了还是没减呢？如果减了是回滚还是继续发送确认消息呢？RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。如下图：

总结：据笔者的了解，各大知名的电商平台和互联网公司，几乎都是采用类似的设计思路来实现“最终一致性”的。这种方式适合的业务场景广泛，而且比较可靠。不过这种方式技术实现的难度比较大。目前主流的开源MQ（ActiveMQ、RabbitMQ、Kafka）均未实现对事务消息的支持，所以需二次开发或者新造轮子。比较遗憾的是，RocketMQ事务消息部分的代码也并未开源，需要自己去实现。

MQ（非事务消息）：

通常情况下，在使用非事务消息支持的MQ产品时，我们很难将业务操作与对MQ的操作放在一个本地事务域中管理。通俗点描述，还是以上述提到的“跨行转账”为例，我们很难保证在扣款完成之后对MQ投递消息的操作就一定能成功。这样一致性似乎很难保证。

先从消息生产者这端来分析，请看伪代码：

根据上述代码及注释，我们来分析下可能的情况：

  1.操作数据库成功，向MQ中投递消息也成功，皆大欢喜
  2.操作数据库失败，不会向MQ中投递消息了
  3.操作数据库成功，但是向MQ中投递消息时失败，向外抛出了异常，刚刚执行的更新数据库的操作将被回滚

 
 
   
   
   
   

 
 
   
   
   
   

    
    
    
    
1
    
    
    
    
2
    
    
    
    
3
   
   
   
   

从上面分析的几种情况来看，貌似问题都不大的。那么我们来分析下消费者端面临的问题：

  1.消息出列后，消费者对应的业务操作要执行成功。如果业务执行失败，消息不能失效或者丢失。需要保证消息与业务操作一致
  2.尽量避免消息重复消费。如果重复消费，也不能因此影响业务结果

 
 
   
   
   
   

 
 
   
   
   
   

    
    
    
    
1
    
    
    
    
2
   
   
   
   

如何保证消息与业务操作一致，不丢失？

主流的MQ产品都具有持久化消息的功能。如果消费者宕机或者消费失败，都可以执行重试机制的（有些MQ可以自定义重试次数）。

如何避免消息被重复消费造成的问题？

1.保证消费者调用业务的服务接口的幂等性
2.通过消费日志或者类似状态表来记录消费状态，便于判断（建议在业务上自行实现，而不依赖MQ产品提供该特性）

 
 
   
   
   
   

 
 
   
   
   
   

    
    
    
    
1
    
    
    
    
2
   
   
   
   

总结：这种方式比较常见，性能和吞吐量是优于使用关系型数据库消息表的方案。如果MQ自身和业务都具有高可用性，理论上是可以满足大部分的业务场景的。不过在没有充分测试的情况下，不建议在交易业务中直接使用。

其他补偿方式

做过支付宝交易接口的同学都知道，我们一般会在支付宝的回调页面和接口里，解密参数，然后调用系统中更新交易状态相关的服务，将订单更新为付款成功。同时，只有当我们回调页面中输出了success字样或者标识业务处理成功相应状态码时，支付宝才会停止回调请求。否则，支付宝会每间隔一段时间后，再向客户方发起回调请求，直到输出成功标识为止。

其实这就是一个很典型的补偿例子，跟一些MQ重试补偿机制很类似。

一般成熟的系统中，对于级别较高的服务和接口，整体的可用性通常都会很高。如果有些业务由于瞬时的网络故障或调用超时等问题，那么这种重试机制其实是非常有效的。

当然，考虑个比较极端的场景，假如系统自身有bug或者程序逻辑有问题，那么重试1W次那也是无济于事的。那岂不是就发生了“明明已经付款，却显示未付款不发货”类似的悲剧？

其实为了交易系统更可靠，我们一般会在类似交易这种高级别的服务代码中，加入详细日志记录的，一旦系统内部引发类似致命异常，会有邮件通知。同时，后台会有定时任务扫描和分析此类日志，检查出这种特殊的情况，会尝试通过程序来补偿并邮件通知相关人员。

在某些特殊的情况下，还会有“人工补偿”的，这也是最后一道屏障。

综上我们设计自己的分布式事务：

//案例
 1.消息提供者确保发送消息无异常，否则rollback对数据库的操作。
 2.消费端虽然有持久化存储和重试机制，最好将消息加入到java本地队列中。
 3.消费端为单独一个服务，轮询监听本地队列中的消息，执行核心业务。
 4.记录日志，异常后从新放到本地队列中。根据具体业务设置补偿次数等（可避免因bug 导致无限补偿）。
 5.视业务需要，是否需要开发管理页面进行人工在次对未完成业务的消息进行补偿。

小结：这样即可保证提供者和消费者两台服务保证 “数据的一致性” 。

 
 
   
   
   
   

 
 
   
   
   
   

    
    
    
    
1
    
    
    
    
2
    
    
    
    
3
    
    
    
    
4
    
    
    
    
5
    
    
    
    
6
    
    
    
    
7
    
    
    
    
8
    
    
    
    
9
   
   
   
   

小结

上诉的几种方案中，笔者也大致总结了其设计思路，优势，劣势等，相信读者已经有了一定的理解。其实分布式系统的事务一致性本身是一个技术难题，目前没有一种很简单很完美的方案能够应对所有场景。具体还是要使用者根据不同的业务场景去抉择。

/***************************************************************************************************************/

TCC模式 ：

TCC事务机制
1. TCC的机制
明眼一看就知道，TCC应该是三个英文单词的首字母缩写而来。没错，TCC分别对应Try、Confirm和Cancel三种操作，这三种操作的业务含义如下：Try：预留业务资源Confirm：确认执行业务操作Cancel：取消执行业务操作 稍稍对照下关系型数据库事务的三种操作：DML、Commit和Rollback，会发现和TCC有异曲同工之妙。在一个跨应用的业务操作中，Try操作是先把多个应用中的业务资源预留和锁定住，为后续的确认打下基础，类似的，DML操作要锁定数据库记录行，持有数据库资源；Confirm操作是在Try操作中涉及的所有应用均成功之后进行确认，使用预留的业务资源，和Commit类似；而Cancel则是当Try操作中涉及的所有应用没有全部成功，需要将已成功的应用进行取消(即Rollback回滚)。其中Confirm和Cancel操作是一对反向业务操作。

简而言之，TCC是应用层的2PC(2 Phase Commit, 两阶段提交)，如果你将应用看做资源管理器的话。
详细来说，TCC每项操作需要做的事情如下：Try：尝试执行业务。完成所有业务检查(一致性)预留必须业务资源(准隔离性)Confirm：确认执行业务。真正执行业务不做任何业务检查只使用Try阶段预留的业务资源Cancel：取消执行业务释放Try阶段预留的业务资源 用一张图来说明TCC的机制：

一个完整的TCC事务参与方包括三部分：主业务服务：主业务服务为整个业务活动的发起方，如前面提到的组合支付场景，支付系统即是主业务服务。从业务服务：从业务服务负责提供TCC业务操作，是整个业务活动的操作方。从业务服务必须实现Try、Confirm和Cancel三个接口，供主业务服务调用。由于Confirm和Cancel操作可能被重复调用，故要求Confirm和Cancel两个接口必须是幂等的。前面的组合支付场景中的余额系统和红包系统即为从业务服务。
业务活动管理器：业务活动管理器管理控制整个业务活动，包括记录维护TCC全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作。
可见整个TCC事务对于主业务服务来说是透明的，其中业务活动管理器和从业务服务各自干了一部分工作。
2. TCC的优点和限制
TCC事务的优点如下：解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用。TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交，规避了数据库层的2PC性能低下问题。 TCC事务的缺点，主要就一个：
TCC的Try、Confirm和Cancel操作功能需业务提供，开发成本高。
当然，对TCC事务的这个缺点是否是缺点，是一个见仁见智的事情。

3. 一个案例理解TCC
说实话，TCC的理论有点让人费解。故接下来将以账务拆分为例，对TCC事务的流程做一个描述，希望对理解TCC有所帮助。
账务拆分的业务场景如下，分别位于三个不同分库的帐户A、B、C，A和B一起向C转帐共80元：

Try：尝试执行业务。完成所有业务检查(一致性)：检查A、B、C的帐户状态是否正常，帐户A的余额是否不少于30元，帐户B的余额是否不少于50元。预留必须业务资源(准隔离性)：帐户A的冻结金额增加30元，帐户B的冻结金额增加50元，这样就保证不会出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中，帐户A和B的可用余额不够的情况。Confirm：确认执行业务。真正执行业务：如果Try阶段帐户A、B、C状态正常，且帐户A、B余额够用，则执行帐户A给账户C转账30元、帐户B给账户C转账50元的转帐操作。不做任何业务检查：这时已经不需要做业务检查，Try阶段已经完成了业务检查。只使用Try阶段预留的业务资源：只需要使用Try阶段帐户A和帐户B冻结的金额即可。Cancel：取消执行业务释放Try阶段预留的业务资源：如果Try阶段部分成功，比如帐户A的余额够用，且冻结相应金额成功，帐户B的余额不够而冻结失败，则需要对帐户A做Cancel操作，将帐户A被冻结的金额解冻掉。 小结：到底要不要使用TCC 到底要不要使用TCC事务，取决于以下几点：是否真正有保证跨应用业务操作的原子性需求。研发上能否投入资源开发相对应的TCC接口。
当然还有最后一点，能否搞定一个稳定的、高可用的、扩展性强的TCC事务管理器。
一个问题，如果TCC事务在Try阶段所有参与方(从业务服务)成功了，但是Confirm阶段部分参与方(从业务服务)成功，如何处理？
TCC参考资料《大规模SOA系统中的分布式事务处理》。

幂等性 ：

什么是幂等性

抄用一段数学上的定义：f(f(x)) = f(x)。x被函数f作用一次和作用无限次的结果是一样的。幂等性应用在软件系统中，我把它简单定义为：某个函数或者某个接口使用相同参数调用一次或者无限次，其造成的后果是一样的，在实际应用中一般针对于接口进行幂等性设计。举个栗子，在系统中，调用方A调用系统B的接口进行用户的扣费操作时，由于网络不稳定，A重试了N次该请求，那么不管B是否接收到多少次请求，都应该保证只会扣除该用户一次费用。

//小编个人理解
我们主题是 “分布式事务” ，在我们的上述分布式几种事务解决方案中，要保证幂等，我们可以通过日志+数据库锁（其他分布式锁也可）等来保证无论接口调用几次，都只之执行一次，不会因为执行多次而改变真实的数据。

 
 
   
   
   
   

 
 
   
   
   
   

    
    
    
    
1
    
    
    
    
2
    
    
    
    
3