RocketMQ的事务投递

RocketMQ的事务投递

这是阿里的分布式事务图：

• 一、A服务先发送个Half Message给Brock端，消息中携带 B服务 即将要+100元的信息。
• 二、当A服务知道Half Message发送成功后，那么开始第3步执行本地事务。
• 三、执行本地事务(会有三种状况一、执行成功。二、执行失败。三、网络等缘由致使没有响应)
• 4.1)、若是本地事务成功，那么Product像Brock服务器发送Commit,这样B服务就能够消费该message。
• 4.2)、若是本地事务失败，那么Product像Brock服务器发送Rollback,那么就会直接删除上面这条半消息。
• 4.3)、若是由于网络等缘由迟迟没有返回失败仍是成功，那么会执行RocketMQ的回调接口,来进行事务的回查。

若是回查，那么必定要先查看当前事务的执行状况，再看是否须要从新执行本地事务。 本地事务执行成功后，返回Commit进行消息二次确认的时候的服务挂了，在重启服务那么这个时候在brock端，它仍是个Half Message(半消息)，这也会回查。若是不先查看当前事务的执行状况，而是直接执行事务，那么就至关于成功执行了两个本地事务。

基于MQ的事务处理特色

最终一致性

RocketMQ是一种最终一致性的分布式事务，就是说它保证的是消息最终一致性，而不是像2PC、3PC、TCC那样强一致分布式事务，至于为何说它是最终一致性事务下面会详细说明。

Half Message(半消息)

是指暂不能被Consumer消费的消息。Producer 已经把消息成功发送到了 Broker 端，但此消息被标记为暂不能投递状态，处于该种状态下的消息称为半消息。须要 Producer

对消息的二次确认后，Consumer才能去消费它。

消息回查

因为网络闪段，生产者应用重启等缘由。致使 Producer 端一直没有对 Half Message(半消息) 进行 二次确认。这是Brock服务器会定时扫描长期处于半消息的消息，会

主动询问 Producer端 该消息的最终状态(Commit或者Rollback),该消息即为 消息回查。

一个例子

如下单流程为例：