一句话：

分布式事务发起方和联动方割裂开来，通过记录跟分析前一个事务的运行状态，决定下一步的行为是回
滚还是开启下游事务

具体点

"割裂"：
    割裂意味着每个事务是独立提交的，这是最终一致模型。从代码上来开，也不再是同一个方法内，
    通过调用开启另外的事务了。即原来的业务逻辑：
        func(){
            执行本地事务A
            执行远程事务B
        }
        
    割裂后业务逻辑:
        func(){
            执行本地事务A
            在事务A提交的同时记录事务信息
        }
        

"记录跟分析前一个事务的运行状态"：
    先谈谈如何记录事务的运行状态信息。我们最容易想到的方案就是在同一个本地事务内，提交的同
    时插入一条事务状态信息数据即可。这样，只要我们保证了事务提交，必然有相关信息数据持久，
    对一个分布式事务而言，我们可用唯一的xid字段去标记，如此，无论这一组次的子事务状态数据
    是否在同一个库，我们都能轻易的找到他们。

    另外，在事务提交的同时，如果能够发送一条可靠消息，那么也能达到持久的目的，这是消息驱动
    采用的方式，但在后面会说到，发送一条可靠消息，可能并不是那么容易。


"去决定下一步的行为"：
    我们不妨从分布式事务的源头来看，发起方的本地事务提交了，假如相关的带有唯一标志xid的事
    务信息被插入了数据库，这个时候，如果我们有一个独立的观察者，发现了这样的一条事务信息，
    若检查事务信息的状态是本地提交，那么观察者会根据相关的业务信息去开启下游事务逻辑，直至
    整个业务逻辑完成，或执行各自的回滚逻辑，这便是消息驱动的核心原理。
    
    思考一下，独立的观察者的实现方案。
   
    1。可以通过异步的定时任务去捞取信息
    2。可以通过订阅binlog去实现事务信息的消费
    3。借助于消息中间件MQ，这是本章将介绍的内容
    
    我们采用MQ的模式，于是整个分布式事务的逻辑变成了这样：        
    
        提交上游事务 -> 发送了一条可靠消息  -> 下游事务消费消息  -> 回滚或者继续驱动 

更进一步

消息驱动的链路逻辑清楚了，但是这条链路上的问题依旧很多，这里我们进入更深一步的讨论。

1。如何在上游事务提交的同时发送一条可靠消息。
    
    从单个事务的生命周期来看，我们无外乎在提交前跟提交后发送消息而已，假设先在MQ正常的情况
    下讨论
    
    a.如果在提交前发送消息，本地事务异常失败了，消息却被消费了，明显产生了问题。
    b.如果在提交后发送消息，jvm挂了或者网络问题，引发消息发送失败，这又产生了问题。
    
    其实解决也不复杂，我们只需要在提交前发送一种不被消费的消息，在提交后再修改这条消息的状
    态让它具备被消费的能力即可，这种功能在RocketMq被叫做事务消息,没有被确认状态的消息称为
    半消息。
    
    回头看
    问题a 被解决了，没有被确认的消息叫做半消息，不能被消费，我们借助于发送消息的ack机制，
    保证事务提交前发送成功。
    
    在看问题b 半消息发送了，本地事务提交后jvm挂掉了，怎么办？ 聪明的你已经想到了,那就是和
    本地事务一同插入的，本地事务表信息！
    
    我们提供给mq一个回查机制，当半消息迟迟得不到确认，那么去回查，发现相关xid标记的本地事
    务已经插入了且状态是本地已经提交了，那么自然而然，这条半消息状态可以修改为已完成，可以
    被消费了。
    
    否则呢？否则这条消息就应该状态修改为回滚！让相关的消费服务执行回滚逻辑！
    
2。如何保证能够正确的消费掉这条事物消息
    消费方需要做到接口等幂，若多次尝试消费失败，最终到达死信队列。

简单总结

对比TCC方案，很明显，我们不要去做最难的业务资源预留的设计。
借助于中间件，提升了维护难度，还是买人家的服务来用吧。