学习一下分布式事务。
这篇文章尽可能的压缩篇幅，不做过多的介绍，像什么是事务就不介绍了。
这里也分享一篇详细的分布式事务相关的文章：https://juejin.im/post/5b5a0bf9f265da0f6523913b
# # 什么是分布式事务
分布式事务一定来源于多数据源。如果只有一个数据源，也就不存在什么分布式事务了。
分布式事务往往来源于，服务拆分后，每个服务都有自己数据库，然后变成了多数据源，本地事务已经不能再去处理事务了。
来个例子就是：
# # 为什么会有分布式事务
区分于本地事务，数据库本来是给我们提供事务支持的。 在多数据源以后，本地事务已经不能不能解决事务的问题。所以有了分布式事务。
来看一个例子，为什么本地事务解决不了分布式事务的问题，又或者说，用本地事务解决分布式事务有什么问题？
在多数据源的时候，一定会有这样的问题可能发生，就是对于两个数据库的操作，相当于是两个本地事务，但是两个本地事务并不能协作。如果 A数据源的事务提交成功了，而 B没有提交成功。
# # 如何去解决分布式事务
对于分布式事务的解决，像这种两个本地事务不能彼此通信的话，那就只能是通过第三个人，作为统一事务管理者，来协调两个本地事务。
# # 先看分布式事务协议
# # 分布式事务解决方案（理论部分）：两阶段提交
所谓两阶段提交，就是分为：准备阶段，和提交/回滚阶段
两阶段提交，是基于XA协议的，强一致性的
找一个中间人，作为分布式事务管理者，分阶段来处理。解决的上边提到的本地事务出现的问题。就是事务提交统一听指挥，最后提交结果都告诉我，都成功就提交，有一个失败就回滚。
这里为了方便理解，举一个例子，就像是有游戏里边的组队打副本。一般都要有一个队长，开始打之前，对账会发一个通知，准备好打了吗？到队员那里去，所有的队员都有点准备好了。对账看到多有的人都回复了准备开了，就开始进副本了。如果有一个人回复没有准备好，或者迟迟没有回复，那队长就不开副本，并且告知其它队友，有一个货还没准备好，先不开始打，什么时候打，我再通知。
分析一下两阶段提交的问题：比方说询问的时候，明明事务没有接到 准备的通知，或者事务的参与者准备好了，却发了回了准备好的信息，事务管理者却没有收到。同理，在 commit 阶段 同样会有这样问题。
# # 分布式事务解决方案（理论部分）：三阶段提交
三阶段提交就是未来解决两阶段提交的问题，加一个阶段，超时阶段。
# # 分布式事务解决方案（理论部分）:TCC事务
TCC 事务是最终一致性，是两阶段提交的一个变种。
具体实现方案有：本地消息表，MQ
# #分布式事务解决方案 ：saga事务
~
# # 这么多分布式解决方案，到底选哪一个呢
其中两阶段提交已经有开源的方案，而阶段提交却没有一个具体的开源方案，因为具体超时的原因不知道，实现没有意义。
