分布式事务-XA协议和MQ分布式事务解决

XA分布式事务

分布式事务常用于分布式系统中，保证各个节点之前数据一致性。比较代表的是oracle提出的XA分布式事务协议
XA协议包含两阶段提交（2PC）和三阶段提交（3PC）两种实现，这里我们重点介绍两阶段提交的具体过程。

在XA分布式事务的第一阶段prepare
1.作为事务协调者（事务管理器）会首先向所有的参与者（资源管理器）发送Prepare请求，通知他们开始准备事务。
2.事务参与者受到接收到消息后开始准备，写好日志并且开始执行事务，但是不提交，然后将是否就绪的消息返回事务管理器。（此时事务已经大部分做完，后面耗时极少）。
接着进入第二阶段：
事务管理器接受到消息之后开始分析，如果有任意的数据库失败，则发送回滚命令，否则发送提交命令。
各个资源管理器接收到命令之后，开始执行命令，并将提交的消息返回给事务管理器。

XA两阶段提交的不足

1. 性能问题
   XA协议遵循强一致性，事务管理器要收集各个资源管理器的响应消息，如果其中一个或多个一直不返回消息，则事务管理器一直等待，应用程序也被阻塞，甚至可能永久阻塞。

2. 协调者单点故障问题
   事务协调者是整个XA协议核心，一旦挂掉，那么参与者接收不到提交或者回滚通知，参与者就一直处理中间状态，无法完成事务。（解决：如果协调者挂掉,可以重新选举一个协调者，查询所有参与者的状态是否有 commit 的，如果有，则继续 commit，如果都没有，则 abort）

3. 数据不一致问题。
   一部分参与者接收到了commit指令，另一部分一部分没有接收到，就会出现各个系统的数据不一致问题。（解决： 重启参与者，通过询问协调者，从而知道事务是否需要提交）

解决

• 如果避免XA两阶段提交的种种问题呢？有许多其他的分布式事务方案可供选择.

1. XA 三阶段提交
   XA三阶段提交在两阶段提交的基础上增加了Cancommit，并且引入了超时机制，一旦事务参与者迟迟没有接到协调者的commit请求，会自动进行本地commit。这样有效解决了协调者单点故障的问题。但是性能问题和不一致的问题仍然没有根本解决。
2. MQ事务
   利用消息中间件来异步完成事务的后一半更新，实现系统的最终一致性。这个方式避免了像XA协议那样的性能问题。
   当然还有seata，这里先不做介绍

• MQ 分布式事务主要有以下特点
  两阶段提交
  补偿事务
  本地消息表
  MQ 事务消息

• 比如
  比如支付系统和订单系统，支付成功之后需要更新订单状态。
  可以在支付服务完成支付步骤后，往MQ发送一条已支付消息，订单服务收到消息后更改订单状态。
  这里面主要用到两阶段提交。
  支付服务保证支付成功之后的消息发送成功，MQ保证消息不会丢失，B服务保证消息消费成功。

1. 支付服务生产消息失败，回滚支付操作，业务达到最初状态，保证了一致性。
2. 支付服务生产消息成功，MQ宕机，重启后，消息依然存在，订单消费消息，保证一致性
3. 订单服务消费消息失败，消息还是存在的，订单服务重启之后继续消费消息，保证了最终一致性。

• 这里面关键是如何保证消息被可靠的投递，不要出现不一致状态。因为支付扣款操作和消息投递操作也是两个步骤。这里面可以用两阶段提交的技术。

  生产者向MQ发送消息后，MQ将此消息保存，但是不提交，消费者还看不到这个消息。这种叫半消息
  然后生产者开始执行自己的事务，把执行结果二次确认的状态告诉MQ，成功就commit消息，失败就删除消息。
  如果MQ一直没有收到生产者发过来的二次确认的状态，那么MQ服务就会对该消息发送回查，最终拿到消息状态。