分布式事务之可靠消息最终一致性

消息发送一致性：是指产生消息的业务动作与消息发送的一致。也就是说，如果业务操作成功，那么由这个业务操作所产生的消息一定要成功投递出去(一般是发送到kafka、rocketmq、rabbitmq等消息中间件中)，否则就丢消息。

可靠消息最终一致性

发送消息不可靠性

既然提到了可靠消息的最终一致性，那么说明现有的消息发送逻辑存在不可靠性，我们用下面的几种情况来演示消息的不可靠性。

• 先进行数据库操作，再发送消息：

  public void test1(){
  //1 数据库操作
  //2 发送MQ消息
  }
  

  这种情况下无法保证数据库操作与发送消息的一致性，因为可能数据库操作成功，发送消息失败

• 先发送消息，再操作数据库：

  public void test1(){
  //1 发送MQ消息
  //2 数据库操作
  }
  

  这种情况下无法保证数据库操作与发送消息的一致性，因为可能发送消息成功，数据库操作失败。

• 在数据库事务中，先发送消息，后操作数据库：

  @Transactional
  public void test1(){
  //1 发送MQ消息
  //2 数据库操作
  }
  

  这里使用spring 的@Transactional注解，方法里面的操作都在一个事务中。同样无法保证一致性，因为发送消息成功了，数据库操作失败的情况下，数据库操作是回滚了，但是MQ消息没法进行回滚。

• 在数据库事务中，先操作数据库，后发送消息：

  @Transactional
  public void test1(){
  //1 数据库操作
  //2 发送MQ消息
  }
  

  这种情况下，貌似没有问题，如果发送MQ消息失败，抛出异常，事务一定会回滚(加上了@Transactional注解后，spring方法抛出异常后，会自动进行回滚)。
  这只是一个假象，因为发送MQ消息可能事实上已经成功，如果是响应超时导致的异常。这个时候，数据库操作依然回滚，但是MQ消息实际上已经发送成功，导致不一致。

• 使用JTA事务管理器：

  前面通过spring的@Transactional注解加在方法上，来开启事务。其实有一个条件没有明确的说出来，就是我们配置的事务管理器是DataSourceTransactionManager。

  事实上，Spring还提供了另外一个分布式事务管理器JtaTransactionManager。这个是使用XA两阶段提交来保证事务的一致性。当然前提是，你的消息中间件是实现了JMS规范中事务消息相关API（回顾前面我们介绍JTA规范时，提到DB、MQ都只是资源管理器RM，对于事务管理器来说，二者是等价的）。

  因此如果你满足了2个条件：1、使用JtaTransactionManager 2、DB、MQ分别实现了JDBC、JMS规范中规定的RM应该实现的两阶段提交的API，就可以保证消息发送的一致性。

  DB作为RM，一般都是支持两阶段提交的。不过，一些MQ中间件并不支持，所以你要找到支持两阶段提交的MQ中间件。另外，JtaTransactionManager只是一个代理，你需要提供一个真实的事务管理器(TM)实现。如前面提到了atomikos公司，就有这样的产品。

  但是笔者依然不建议，这样做。因为XA两阶段提交性能低，我们使用消息中间件就是为了异步解耦，这种情况，虽然保证了一致性，但是响应时间却大大增加，系统可用性降低。

可靠发送消息的解决方案

有两种方法可以实现可靠消息发送：基于MQ的事务消息和本地事务表。

基于MQ的事务消息

以RocketMQ的事务消息为例，如下图所示，消息的可靠发送由发送端 Producer进行保证(消费端无需考虑)，可靠发送消息的步骤如下：

1. 发送一个事务消息，这个时候，RocketMQ将消息状态标记为Prepared，注意此时这条消息消费者是无法消费到的；
2. 执行业务代码逻辑，可能是一个本地数据库事务操作；
3. 确认发送消息，这个时候，RocketMQ将消息状态标记为可消费，这个时候消费者，才能真正的保证消费到这条数据。

如果确认消息发送失败了怎么办？RocketMQ会定期扫描消息集群中的事务消息，如果发现了Prepared消息，它会向消息发送端(生产者)确认。RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

如果消费失败怎么办？阿里提供给我们的解决方法是：人工解决。

本地事务表

并不是所有的mq都支持事务消息。也就是消息一旦发送到消息队列中，消费者立马就可以消费到。此时可以使用独立消息服务、或者本地事务表。

可以看到，其实就是将消息先发送到一个我们自己编写的一个"独立消息服务"应用中，刚开始处于prepare状态，业务逻辑处理成功后，确认发送消息，这个时候"独立消息服务"才会真正的把消息发送给消息队列。消费者消费成功后，ack时，除了对消息队列进行ack(图中没有画出)，对于独立消息服务也要进行ack，"独立消息服务"一般是把这条消息删除。而定时扫描prepare状态的消息，向消息发送端(生产者)确认的工作也由独立消息服务来完成。

对于"本地事务表"，其实和"独立消息服务"的作用类似，只不过"独立消息服务"是需要独立部署的，而"本地事务表"是将"独立消息服务"的功能内嵌到应用中。