分布式事务

 学习一下分布式事务。

 这篇文章尽可能的压缩篇幅，不做过多的介绍，像什么是事务就不介绍了。

# # 什么是分布式事务

  分布式事务一定来源于多数据源。如果只有一个数据源，也就不存在什么分布式事务了。 

  分布式事务往往来源于，服务拆分后，每个服务都有自己数据库，然后变成了多数据源，本地事务已经不能再去处理事务了。

  来个例子就是：

# # 为什么会有分布式事务

  区分于本地事务，数据库本来是给我们提供事务支持的。 在多数据源以后，本地事务已经不能不能解决事务的问题。所以有了分布式事务。

  来看一个例子，为什么本地事务解决不了分布式事务的问题，又或者说，用本地事务解决分布式事务有什么问题？

 在多数据源的时候，一定会有这样的问题可能发生，就是对于两个数据库的操作，相当于是两个本地事务，但是两个本地事务并不能协作。如果 A数据源的事务提交成功了，而 B没有提交成功。 

# # 如何去解决分布式事务

 对于分布式事务的解决，像这种两个本地事务不能彼此通信的话，那就只能是通过第三个人，作为统一事务管理者，来协调两个本地事务。

# # 先看分布式事务协议

# # 分布式事务解决方案（理论部分）：两阶段提交

  所谓两阶段提交，就是分为：准备阶段，和提交/回滚阶段

  两阶段提交，是基于XA协议的，强一致性的

  找一个中间人，作为分布式事务管理者，分阶段来处理。解决的上边提到的本地事务出现的问题。就是事务提交统一听指挥，最后提交结果都告诉我，都成功就提交，有一个失败就回滚。

  这里为了方便理解，举一个例子，就像是有游戏里边的组队打副本。一般都要有一个队长，开始打之前，对账会发一个通知，准备好打了吗？到队员那里去，所有的队员都有点准备好了。对账看到多有的人都回复了准备开了，就开始进副本了。如果有一个人回复没有准备好，或者迟迟没有回复，那队长就不开副本，并且告知其它队友，有一个货还没准备好，先不开始打，什么时候打，我再通知。

  分析一下两阶段提交的问题：比方说询问的时候，明明事务没有接到 准备的通知，或者事务的参与者准备好了，却发了回了准备好的信息，事务管理者却没有收到。同理，在 commit 阶段 同样会有这样问题。

# # 分布式事务解决方案（理论部分）：三阶段提交

 三阶段提交就是未来解决两阶段提交的问题，加一个阶段，超时阶段。

# #  分布式事务解决方案（理论部分）:TCC事务

 TCC 事务是最终一致性，是两阶段提交的一个变种。

 具体实现方案有：本地消息表，MQ

# #分布式事务解决方案 ：saga事务

 ~

# # 这么多分布式解决方案，到底选哪一个呢

  其中两阶段提交已经有开源的方案，而阶段提交却没有一个具体的开源方案，因为具体超时的原因不知道，实现没有意义。