文档介绍：分布式事务解决方案总结
 
   
 
 
 
 
 
 
 
     
 
 
 
 
 
1. 背景
数据库里的事务大家都不陌生，而在微服务架构中由于一个任务执行可能涉及多个微服务，要想在分布段：完成所有业务检查（一致性），预留业务资源(准隔离性)
Confirm 阶段：确认执行业务操作，不再做任何业务检查， 只使用Try阶段预留的业务资源。
Cancel 阶段： 取消Try阶段预留的业务资源。
TCC 提供了三个阶段约定，因此可适用于 业务操作，而不局限在数据库。
TCC 不会一直持有资源锁，它的理念是 “ 先检查资源可用，再执行，大不了就回滚 ” 1、try 是保证资源预留的业务逻辑的正确性。 2、confirm/cancel 执行的本地事务逻辑确认
/取消预留资源，以保证最终一致性。
优点：有效了的避免了 2PC 提交占用资源锁时间过长导致的性能地下问题。
缺点：主业务服务和从业务服务都需要进行改造，从业务方改造成本更高。
(3) 本地消息表
本地消息表其实就是利用了 各系统本地的事务来实现分布式事务。
、就是会有一张存放“本地消息”的表，它和业务数据表在一个数据库中，以充分利用数据库的事务。
、在执行业务的时候 “ 将业务的执行 ” 和 “将消息放入消息表中的操作” 放在同一个事务中，以确保是一起执行的。
、再需要一个后台任务，它定时去读取“ 本地消息表 ”，筛选出还“ 未成功 ”的消息，按消息描述执行业务操作，如果执行成功则移除消息（或更新消息状态），如果执行失败则会继续重试。当然这里的过程也可以结合利用 MQ（消息队列）来发送消息到其他业务服务。
本地消息表实现的是最终一致性，容忍了数据暂时不一致的情况。
优点是简单。 缺点是严重依赖数据库。
(4) 消息事务
消息事务 利用消息中间件来实现，“事务发起方” 在执行完成本地事务后发出一条消息，然后 “事务参与方(接收消息的一方)" 接收消息并处理任务，它强调是最终一致性。
可以利用 RocketMQ 的 Half Message（半消息）实现一个消息事务。
、服务A，先给 Broker(消息中间件) 发送一个 Half Message（半消息），其实这个半消息已发送到 Broker端，但是此消息的状态被标记为"不能投递"，消费者还看不到，处于这种状态下的消息称为半消息。
、发送完 半消息后，服务A 执行业务操作（本地事务），再根据操作结果： ___ 如果成功，则向 Broker 发送 一个 Commit 命令，这时 半消息就变成了正儿八经的消息，就可以被消费者消息了。 ___ 如果失败，则发送一个 RollBack 命令，该消息则会被删除。
、参与方（消息消费者）读取消息并执行任务。
、RocketMQ 的反查：对于 半消息 RocketMQ 会自动定时轮询回调你的接口，询问这个处理的处理情况。借助这点，服务A实现一个回调，根据实际处理结果 Commit 或者 Rollback，加强一致性判断。
可靠消息最终一致性方案。
如果不用RocketMQ，也可以基于 ActiveMQ 或者 RabbitMQ 自己封装一套这套逻辑出来。
(5) 最大努力通知方案