1.已经做的事

首先我们不会重复造轮子，因为如果市面上已经存在很好很优秀的框架或者解决方案，那么我建议使用那些成熟的解决方案。

那么比如说，我之前实现的可靠消息最终一致性方案（rtm），就是利用了其他mq没有事务消息这个特征(Rocketmq独有)，但是又想在不改用mq的前提下，那么又想保证数据最终一致性，那么就可以使用rtm系统来作为中间商 协调上下游系统的事务处理，保证了数据的最终一致性。

话句话说，RTM实际上是基于本地消息表这种解决方案来实现的。而且实际上rtm的理念其实就是跟rocketmq的事务消息类似，但是rtm更加全面。

rocketmq事务消息的弊端

我们知道， 事务消息 仅仅只是保证本地事务和MQ消息发送形成整体的 原子性，而投递到MQ服务器后，并无法保证消费者一定能消费成功！也就是下游系统可能会发送失败。

如果 消费端消费失败 后的处理方式，建议是记录异常信息然后 人工处理，并不建议回滚上游服务的数据(因为两者是解耦的，而且 回滚复杂度 太高)

那么如果使用事务消息怎么解决下游系统消费失败的问题呢？

常见两个解决方案：

我们可以利用 MQ 的两个特性 重试 和 死信队列 来协助消费端处理：

消费失败后mq进行一定次数的 重试
重试后也失败的话该消息丢进 死信队列 里
另外起一个线程监听消费 死信队列 里的消息，记录日志并且预警！

因为有 重试 所以消费者需要实现 幂等性

RTM系统优点 - 广告一波

在兼有rocketmq事务消息的同时，能够保证下游系统一定能消费消息（提供消费失败一定次数和时间间隔重试以及记录超过重试次数的消息），从而保证了数据的最终一致性，同时提供管理界面，管理已经超过重发次数上限的消息，重新发送。

所以说，当你的项目架构在最初的技术选型时，并没有使用rocketmq，那么又想保证数据最终一致性，那么就可以引入rtm系统，非常方便快捷。

2.分布式事务选型

分布式解决方案，一般有如下几种：

XA分布式协议
- 2pc - 一般不适用
- 3pc

TCC
- Try、Confirm、Cancel，实际上用到了补偿的概念
- 这种方案说实话几乎很少用人使用，我问过得人，用的也比较少，但是也有使用的场景。因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿，会造成补偿代码巨大，非常之恶心。
  
  比如说我们，一般来说跟钱相关的，跟钱打交道的，支付、交易相关的场景，我们会用TCC，严格严格保证分布式事务要么全部成功，要么全部自动回滚，严格保证资金的正确性，在资金上出现问题。
  - 阿里开源的seata，但是阿里的seata并不是纯正的tcc框架，因为纯正的tcc框架，很麻烦，需要你手动把各种接口实现出来3个接口，try，confirm，cancel。bytetcc框架，就是一个纯的tcc框架，可以了解一下。

可靠消息最终一致性
- 推荐使用
本地消息表
最大努力通知方案
- 这个方案的大致意思就是：
  
  1）系统A本地事务执行完之后，发送个消息到MQ
  
  2）这里会有个专门消费MQ的最大努力通知服务，这个服务会消费MQ然后写入数据库中记录下来，或者是放入个内存队列（DelayQueue）也可以，接着调用系统B的接口
  
  3）要是系统B执行成功就ok了；要是系统B执行失败了，那么最大努力通知服务就定时尝试重新调用系统B，反复N次，最后还是不行就放弃。

实际上rtm系统，已经实现了可靠消息最终一致性和本地消息表这两种方案。

3.自我实现最大努力通知方案

最大努力通知与可靠消息一致性有什么不同

1、解决方案思想不同

可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。

最大努力通知，发起通知方尽最大的努力将业务处理结果通知给接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。

2、两者的业务应用场景不同

可靠消息一致性关注的是交易过程的事务一致，以异步的方式完成交易。

最大努力通知关注的是交易后的通知事务，即将交易结果可靠的通知出去。

3、技术解决方向不同

可靠消息一致性要解决消息从发出到接收的一致性，即消息发出并且被接收到。

最大努力通知无法保证消息从发出到接收的一致性，只提供消息接收的可靠性机制。可靠机制是，最大努力的将消息通知给接收方，当消息无法被接收方接收时，由接收方主动查询消息（业务处理结果）。

也就是我们要实现的最大通知服务关注的是跟下游服务之间的可靠性通信，而可靠消息一致性中可靠消息服务（rtm）关注的是跟上游的数据一致性，同时保证消息一定能发送到下游。