分布式事务

分布式事务

2pc

3pc

tcc（try、confirm、cancel）

这个其实用了补偿机制，分为三个阶段：

1）try阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留

2）confirm阶段：这个阶段说的是在各个服务中执行实际的操作

3）cancel阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作

手动补偿，代码比较复杂，跟钱打交到可以用这个，严格保证事务

 

本地消息表

A事务往消息表存一条消息数据，然后往MQ里也发一条消息，B事务从mq拿到消息后去处理，处理完了也往自己的本地消息表存一条数据，同时去改变自己的状态和A表的状态为已完成。

B事务往自己表里面插数据可以保证幂等性，如果插不进表示完成过这个事务，这个时候会让A回滚，这样保证不会重复处理消息

如果B处理识别了，那么就不会跟新消息表状态，那么此时A系统会定时扫描自己的消息表，如果有没处理的消息，会再次发送到MQ中去，让B再次处理

这个方案保证了最终一致性。

 

可靠消息最终一致性方案

这个的意思，就是干脆不要用本地的消息表了，直接基于MQ来实现事务。比如阿里的RockerMQ就支持消息事务。

大概的意思就是：

A系统首先发送prepared消息给MQ，然后A系统执行本地事务，发confirm消息给mq，mq一旦接收到confirm后就会一直发消息让B事务完成。

A系统如果发送prepared消息给MQ后，MQ一直没有收到confirm消息，或者rollback消息，这个时候MQ会主动发消息回调给A系统，确认事务的一个情况。这个回调接口需要自己写。

 

 

最大努力通知：

和可靠消息最终一致性差不多，简单一点

A系统执行事务，然后发给MQ，MQ发消息给最大努力通知服务，最大努力通知去通知B完成事务，B多次失败就算了。

 

99%的接口调用，不用做分布式事务，直接就是监控（发邮件，发短信）记录日志一旦出错，事后快速定位，排查出解决方案、修复数据。