关于 RocketMQ 事务消息的正确打开方式 → 你学废了吗

开心一刻

　　昨晚和一哥们一起吃夜宵，点了几瓶啤酒

　　不一会天空下起了小雨，哥们突然道：糟了

　　我：怎么了

　　哥们：外面下雨了，我老婆还在等着我去接她

　　他给了自己一巴掌，说道：真他妈不是个东西

　　我心想：哥们真是个好丈夫

　　很快他补充道：喝酒怎么能分心呢

　　我一口啤酒直接笑喷而出

知识回顾

　　本文不讲什么是 RocketMQ ，不讲它的实现原理，只想和大家探讨下它的事务消息的正确使用方式

　　再探讨之前，先带大家回顾下知识点

　　事务消息的设计原理

　　 RocketMQ 在 4.3.0 版中已经支持分布式事务消息，采用 2PC 的思想实现事务消息提交，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息，如下图所示

　　什么，英文看不懂？贴心的我早已想到，中文版的也有

　　其中有两个点：半事务、回查事务状态，值得我们重点回顾

　　Half 消息

　　何谓 half 消息？

　　消息发送方把消息发送到 MQ 服务，但是此消息的状态被标记为不能投递，处于这种状态下的消息称为 half 消息；消费方不能消费 half 消息

　　发送方对 half 消息二次确认后，也就是 Commit 之后，消费方才可以消费到；如果是 Rollback，该消息则会被删除，永远不会被消费到

　　事务状态回查

　　如果在 RocketMQ 事务消息的二阶段过程中失败了，例如在做 Commit 操作时（上图中的第 4 步），出现网络问题导致 Commit 失败，那么需要通过一定的策略使这条消息最终被 Commit

　　RocketMQ 采用了一种补偿机制，称为“回查”。Broker 端对未确定状态的消息发起回查，将消息发送到对应的 Producer 端（同一个 Group 的 Producer），由 Producer 根据消息来检查本地事务的状态，进而执行 Commit 或者 Rollback

　　值得注意的是，RocketMQ 并不会无休止的的信息事务状态回查，默认回查 15 次，如果 15 次回查还是无法得知事务状态，RocketMQ 默认回滚该消息

　　更多细节请查看：事务消息

实战示例

　　理论知识理解之后，就需要我们进行实操与分析了

　　需求背景

　　假设我们有两个服务：订单服务、积分服务，当用户成功下单之后，需要给用户加相应的积分

　　实现方式有很多种，你知道哪些？

　　假设我们用 RocketMQ 事务消息来保证最终一致