分布式事物总体有两类方案：
①刚性方案，全局事物（标准的分布式事物）如二阶段提交协议。
【尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景】
②柔性方案：
1）可靠消息最终一致性（异步确保型）
2）TCC （Try-Confirm-Cancel）（补偿型）
3）最大努力通知（非可靠消息，定期校对）
4）纯补偿型
以下是柔性方案中的几个实现：
可靠消息最终一致性-本地消息服务
可靠消息最终一致性-本地消息服务
可靠消息最终一致性-独立消息服务
如果使用RocketMQ，在本地应用的逻辑代码里（橘黄色字体）可以不用这样写。如果是ActiveMQ、RabbitMQ 和 Kafka需要分三个阶段①预发送消息②业务逻辑③确认发送消息。
RocketMQ事物消息：
第一阶段Prepared消息，会拿到消息的地址。
第二阶段执行本地事务。
第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。
也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。
rocketMq事物消息
最大努力通知
