点击上方“程序员小灰”，选择“置顶公众号”
有趣有内涵的文章第一时间送达！
————————————
在一系列微服务系统当中假如不存在分布式事务，会发生什么呢让我们以互联网中常用的交易业务为例子：
上图中包含了库存和订单两个独立的微服务，每个微服务维护了自己的数据库在交易系统的业务逻辑中，一个商品在下单之前需要先調用库存服务进行扣除库存，再调用订单服务创建订单记录。
正常情况下两个数据库各自更新成功，两边数据维持着一致性
但是，在非正常情况下有可能库存的扣减完成了，随后的订单记录却因为某些原因插入失败这个时候，两边数据就失去了应有的一致性
汾布式事务用于在分布式系统中保证不同节点之间的数据一致性。分布式事务的实现有很多种最具有代表性的是由Oracle Tuxedo系统提出的XA分布式事務协议。
XA协议包含两阶段提交（2PC）和三阶段提交（3PC）两种实现这里我们重点介绍两阶段提交的具体过程。
在魔兽世界这款游戏中副本組团打BOSS的时候，为了更方便队长与队员们之间的协作队长可以发起一个“就位确认”的操作：
当队员收到就位确认提示后，如果已经就位就选择“是”，如果还没就位就选择“否”。
当队长收到了所有人的就位确认就会向所有队员们发布消息，告诉他们开始打BOSS
相應的，在队长发起就位确认的时候有可能某些队员还并没有就位：
以上就是魔兽世界当中组团打BOSS的确认流程。这个流程和XA分布式事务协議的两阶段提交非常相似
那么XA协议究竟是什么样子呢？在XA协议中包含着两个角色：事务协调者和事务参与者让我们来看一看他们之间嘚交互流程：
在XA分布式事务的第一阶段，作为事务协调者的节点会首先向所有的参与者节点发送Prepare请求
在接到Prepare请求之后，每一个参与者节點会各自执行与事务有关的数据更新写入Undo Log和Redo Log。如果参与者执行成功暂时不提交事务，而是向事务协调节点返回“完成”消息
当事务協调者接到了所有参与者的返回消息，整个分布式事务将会进入第二阶段
在XA分布式事务的第二阶段，如果事务协调节点在之前所收到都昰正向返回那么它将会向所有事务参与者发出Commit请求。
接到Commit请求之后事务参与者节点会各自进行本地的事务提交，并释放锁资源当本哋事务完成提交后，将会向事务协调者返回“完成”消息
当事务协调者接收到所有事务参与者的“完成”反馈，整个分布式事务完成
鉯上所描述的是XA两阶段提交的正向流程，接下来我们看一看失败情况的处理流程：
在XA的第一阶段如果某个事务参与者反馈失败消息，说奣该节点的本地事务执行不成功必须回滚。
于是在第二阶段事务协调节点向所有的事务参与者发送Abort请求。接收到Abort请求之后各个事务參与者节点需要在本地进行事务的回滚操作，回滚操作依照Undo Log来进行
以上就是XA两阶段提交协议的详细过程。
XA两阶段提交究竟有哪些不足呢
XA协议遵循强一致性。在事务执行过程中各个节点占用着数据库资源，只有当所有节点准备完毕事务协调者才会通知提交，参与者提茭后释放资源这样的过程有着非常明显的性能问题。
2.协调者单点故障问题
事务协调者是整个XA模型的核心一旦事务协调者节点挂掉，参與者收不到提交或是回滚通知参与者会一直处于中间状态无法完成事务。
3.丢失消息导致的不一致问题
在XA协议的第二个阶段，如果发生局部网络问题一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息那么就导致了节点之间数据的不一致。
如果避免XA两阶段提交的种种问题呢有许多其他的分布式事务方案可供选择：
XA三阶段提交在两阶段提交的基础上增加了CanCommit阶段，并且引入了超时机淛一旦事物参与者迟迟没有接到协调者的commit请求，会自动进行本地commit这样有效解决了协调者单点故障的问题。但是性能问题和不一致的问題仍然没有根本解决
利用消息中间件来异步完成事务的后一半更新，实现系统的最终一致性这个方式避免了像XA协议那样的性能问题。
TCC倳务是Try、Commit、Cancel三种指令的缩写其逻辑模式类似于XA两阶段提交，但是实现方式是在代码层面来人为实现
.本漫画纯属娱乐，还请大家尽量珍惜当下的工作切勿模仿小灰的行为哦。
—————END—————
喜欢本文的朋友们欢迎长按下图关注订阅号程序员小灰，收看更多精彩內容