RocketMQ 分布式事务消息过程分析

• 生产环境最小单元高可用部署模式：

如果192.168.3.100的broker假死，那么3.110,3.111的nameserver都能在2分钟内感知broker-a宕机，然后客户端能成功从nameserver处获得最新的路由信息，

如果nameserver假死，出现超时错误，只要broker不宕机，则通过缓存，还是能正常工作的，

但如果nanmeserver,broker一起假死，则上述架构还是无法规避上面的问题。

最佳实践主要包含如下两条：
1、nameserver与broker一定要分开部署，进行隔离。
2、nameserver与客户端的连接，应该在超时后，关闭连接，触发nameserver漂移，需要修改源码。

• Half Message(半消息)

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

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

• 消息回查

由于网络闪段，生产者应用重启等原因。导致 Producer 端一直没有对 Half Message(半消息) 进行 二次确认。这时Brock服务器会定时扫描长期处于半消息的消息，会主动询问 Producer端 该消息的最终状态(Commit或者Rollback),该消息即为 消息回查。

1. A服务先发送个Half Message给Brock端，消息中携带 B服务 即将要+100元的信息。
2. 当A服务知道Half Message发送成功后，那么开始第3步执行本地事务。
3. 执行本地事务(会有三种情况1、执行成功。2、执行失败。3、网络等原因导致没有响应)
4. 如果本地事务成功，那么Product主动向Brock服务器发送Commit,这样B服务就可以消费该message。
5. 如果本地事务失败，那么Product主动向Brock服务器发送Rollback,那么就会直接删除上面这条半消息。
6. 如果因为网络等原因迟迟没有返回失败还是成功，那么会执行RocketMQ的回调接口,来进行事务的回查（此时由Brock主动发送5）。

详见：浅入浅出-RocketMQ 《浅入浅出》-RocketMQ - 掘金

RocketMQ 消息幂等消费思考逻辑（先登记,再消费）