事务消息介绍
事务消息貌似是阿里提出的分布式事务解决方案，依赖于RocketMQ的事务消息实现（RocketMQ事务消息）。
其核心是通过MQ类似于DB的事务提交或回滚功能+MQ主动回查机制(MQ请求应用)来确保最终的消息确认动作。
它的实现原理也比较简单，我们可以基于上一篇“分布式事务（四）：本地消息表”对照理解。
在本地消息表实现方案中，由于MQ不支持(或者不使用)事务，我们无法确保最终消息投递结果和数据库事务是否保持一致，所以加入了定时任务+本地消息表来进行消息重发机制保障最终一致性。
但是这样使每个服务都存在定时任务和消息表，导致代码逻辑以及数据库表设计和业务耦合严重；所以在事务消息中，将这一部分功能交给MQ进行实现。
MQ事务消息
RocketMQ是支持事务的，其实现原理也是二阶段提交。
也就是说我先发起一个发送消息的动作，但是这个动作类似于db中的声明了一个事务并执行了sql，此时并没有确认提交或者回滚。 然后进行业务处理，处理成功这提交，失败则回滚。
事务消息的回查机制
事务消息回查机制是指，假设客户端发起了一个发送消息的动作，但是后续没响儿了；那MQ怎么办呢，也不能傻等着。
所以MQ就主动的请求服务发起方，来进行询问；这个就是回查机制。
回查机制需要服务发起方进行接口的提供。
事务消息模型
这里画了一个事务消息大致流程：
我们跟着图来解读一下：
- 在事务消息流程中我们将消息发送功能前置，即上图的步骤1，这个时候发送的消息并没进行确认；但是一定要保证发送成功。
- 接下来做业务操作，即上图步骤2；出错了DB就回滚也没事。
- 如果第二步成功，则给MQ发送确认提交动作，即步骤3；表示步骤1的消息已经确认发送。如果在这一步出现了错误（比如“本地消息表”方案中的MQ请求超时等）也没有关系。
- 为什么第二步第三步中出错了也没有关系呢，这个时候就用到了RocketMQ的回查机制，通过MQ主动回查应用接口，确认以上业务动作是否成功。
- 子服务处理完成，通过同样的方式确保通知回调。
在以上流程中，需要对MQ进行2次请求，并且业务方需要在应用中加入一个供MQ回查的接口。
事务消息和其他解决方案对比
- 事务消息和本地消息表一样，在消费方异常的情况下，都是对一个接口进行幂等性多次重试最终达到一致性。
- 相较于TCC或者SAGA没有过多的业务逻辑。
- 理论上来说，服务方也存在多次消费失败的情况，这还是需要人工介入。
- 人工介入流程不管是TCC、SAGA、还是本地消息表都在理论上无法避免。
事务消息的优点
- 相较于TCC，无需进行确认资源以及提交回滚操作，在逻辑上很简单。
- 相较于SAGA，也无需进行正向和逆向补偿。
- 且TCC和SAGA也需要有全局事务协调者的存在，而事务消息中MQ相当于承担了这一角色。
- 相较于本地事务表，消息独立存储，无耦合表结构，业务方代码、表都更纯粹。
- 提供了回查机制保障最终消息确认。
事务消息的缺点
好像没啥缺点，如果非要说有：
- 消息发送需要两次通信。
- 代码中会多加入一个供MQ回查的接口。 有点吹毛求疵了？