RocketMQ事务消息里的补偿机制,有段源码(fillOpRemoveMap)是拉取32条op消息,这个是怎么保证不会重复调用回查方法的?
以下为热心网友提供的参考意见
在RocketMQ中,事务消息的处理主要分为两个阶段:正常事务的发送及提交和事务信息的补偿流程。在正常事务的发送与提交阶段,生产者会发送一个半消息给MQServer,然后服务端响应消息写入结果,半消息发送成功,之后开始执行本地事务,根据本地事务的执行状态执行Commit或者Rollback操作。
事务回查机制是事务消息补偿流程的一部分,主要用于解决生产者在发送Commit或者Rollback操作时发生超时或失败的情况。当MQServer长时间没有收到本地事务的执行状态时,它会向生产者发起一个确认回查的操作请求。生产者在收到确认回查请求后,会检查本地事务的执行状态,然后根据检查后的结果执行Commit或者Rollback操作。
关于源码中的fillOpRemoveMap
方法拉取32条op消息的部分,其具体实现细节并未公开。但是,一般来说,这种设计可能会结合使用时间戳、序列号或者其他唯一标识符来避免重复调用回查方法。例如,每次调用回查方法时,都可能会使用这些唯一标识符来检查是否已经处理过相同的消息。如果已经处理过,那么就不会再调用回查方法。这样,就可以确保同一条消息不会被多次处理,从而避免了重复调用回查方法的可能。
以下为热心网友提供的参考意见
这个没法保证,业务要做好这块的幂等以及事务不阻塞。此回答整理自钉群“群2-Apache RocketMQ 中国开发者钉钉群”
本文来自投稿,不代表新手站长_郑州云淘科技有限公司立场,如若转载,请注明出处:https://www.cnzhanzhang.com/14827.html