java分布式事务——最终一致性，最大努力通知总结！

关于CAP,BASE理论，以及TCC，seata解决方案，可以参考我上一篇博客.《Java分布式事务-seata,tcc解决方案总结》 本文是接着一篇继续的。

4.分布式事务解决方案之可靠消息最终一致性

 4.1.什么是可靠消息最终一致性事务    

    可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。

    此方案是利用消息中间件完成，如下图：

    事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件之间，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。

 因此可靠消息最终一致性方案要解决以下几个问题：

  1.本地事务与消息发送的原子性问题

本地事务与消息发送的原子性问题即：事务发起方在本地事务执行成功后消息必须发出去，否则就丢弃消息。即实现本地事务和消息发送的原子性，要么都成功，要么都失败。本地事务与消息发送的原子性问题是实现可靠消息最

    终一致性方案的关键问题。

    先来尝试下这种操作，先发送消息，再操作数据库：

begin transaction；
  //1.发送MQ
  //2.数据库操作
commit transation;

这种情况下无法保证数据库操作与发送消息的一致性，因为可能发送消息成功，数据库操作失败。你立马想到第二种方案，先进行数据库操作，再发送消息：

begin transaction；
  //1.数据库操作
  //2.发送MQ
commit transation;

  这种情况下貌似没有问题，如果发送MQ消息失败，就会抛出异常，导致数据库事务回滚。但如果是超时异常，数据库回滚，但MQ其实已经正常发送了，同样会导致不一致。

  2、事务参与方接收消息的可靠性

    事务参与方必须能够从消息队列接收到消息，如果接收消息失败可以重复接收消息。

  3、消息重复消费的问题

    由于网络2的存在，若某一个消费节点超时但是消费成功，此时消息中间件会重复投递此消息，就导致了消息的重复消费。

    要解决消息重复消费的问题就要实现事务参与方的方法幂等性。

4.2.解决方案

  4.2.1.RocketMQ事务消息方案

     RocketMQ 是一个来自阿里巴巴的分布式消息中间件，于 2012 年开源，并在 2017 年正式成为 Apache 顶级项目。据了解，包括阿里云上的消息产品以及收购的子公司在内，阿里集团的消息产品全线都运行在 RocketMQ 之上，并且最近几年的双十一大促中，RocketMQ 都有抢眼表现。Apache RocketMQ 4.3之后的版本正式支持事务消息，为分布式事务实现提供了便利性支持。

RocketMQ 事务消息设计则主要是为了解决 Producer 端的消息发送与本地事务执行的原子性问题，RocketMQ 的设计中 broker 与 producer 端的双向通信能力，使得 broker 天生可以作为一个事务协调者存在；而 RocketMQ本身提供的存储机制为事务消息提供了持久化能力；RocketMQ 的高可用机制以及可靠消息设计则为事务消息在系统发生异常时依然能够保证达成事务的最终一致性。

    在RocketMQ 4.3后实现了完整的事务消息，实际上其实是对本地消息表的一