今天在看书的时候，看到了分布式事务的一致性问题，就赶紧记下来。
一、分布式事务介绍
在我们平时写的代码中，我们可以用一个事务包含许多个SQL调用，如果某一个数据库操作发生异常，就可以将之前的SQL操纵全部进行回滚，只有当所以的SQL操作全部成功，才进行提交，这就保证了事务的一致性。
抠张图看看
但是在分布式环境下，多个数据库操作可能被拆分到独立的三个数据库访问服务中，此时原来的本地SQL调用就演变成了远程服务调用，事务的一致性无法得到保证，抠张图来看
加入服务A和服务B调用成功，则A和B的SQL会被提交，最后执行服务C，它的SQL操作失败，那么C进行回滚，在这里，就导致了事务的不一致。
二、分布式事务设计方案
通常，分布式事务基于两阶段实现，它的工作原理示意图如下：
阶段1：全局事务管理器向所有事务参与者发送准备请求，事务参与者向全局事务管理器回复自己是否准备就绪。
阶段2：全局事务管理器接收到所以事务参与者的回复之后做判断，如果所有事务参与者都可以提交，则向所有事务提交者发送提交申请，否则进行回滚。事务参与者根据全局事务管理器的指令进行提交或者回滚操作。
分布式事务回滚图如下：
两个阶段采用的是悲观锁策略，由于各个事务参与者需要等待响应最慢的参与者，因此性能比较差。 而且整个过程都是需要加锁的，并且当协调者出现故障，则整个事务需要等到协调者回复后才能继续执行。
所以可以用最终一致性替代传统的强一致性，尽量避免使用分布式事务。
三、分布式事务优化
在实践中常用的最终一致性方案就是使用带有事务功能的MQ做中间人角色，工作原理如下：
在做本地事务之前，先向MQ发送一个preapre消息，然后执行本地事务，本地事务提交成功的话，向MQ发送一个commit消息，否则发送一个rollback消息，取消之前的消息。MQ只会在收到commit确认才会将消息投递出去，所以这样的形式可以保证在一切正常的情况下，本地事务和MQ可以达到一致性。
但是如果系统执行事务成功后，还没来得及发送commit给MQ，或者说网络超时等问题导致MQ没有收到commit，那么MQ就不会把prepare消息投递出去。MQ会根据策略去尝试询问（回调）发消息的系统进行检查该消息是否应该投递出去或者丢弃，得到系统的确认后，MQ会做投递还是丢弃，这样就完全保证了MQ和发消息的系统的一致性，从而保证了接收消息系统的一致性。