关于业务逻辑与去重表更新操作不在一个原子操作中的问题探讨

[objcoding]

关于业务逻辑与去重表更新操作不在一个原子操作中的问题探讨

[Jaskey]

你好，可以参考这个博文。为什么不做成原子操作是有客观限制的。

http://jaskey.github.io/blog/2020/06/08/rocketmq-message-dedup/

简单说就如文档中所说的那样：极端场景会去重失败，但是不会因为这个去重的逻辑而增加消息的丢失率

[objcoding]

大概明白你的客观因素了，我说下我的理解：
即使你加了本地事务，也不能保证子过程的幂等（子过程可能不支持回滚操作，比如 RPC 调用），意味着这个事务实际上不是原子性的，因此包裹本地事务并不能解决原子性问题，还会大大降低并发度。
为了解决这个通用的场景，你在去重表加了一个状态，把这个操作进行拆分，这样就能就能推广到更复杂的场景例如：RPC、跨库等。

因此，在极端情况下，即使失败了，但 RocketMQ 依然不会因此而丢消息。（在我看来丢消息比重复消费消息更可怕）

[Jaskey]

是的，你的理解很正确。如果业务场景是宁丢勿重，我们去重表的状态逻辑也可以做一些微调，只是目前我的实现不支持这个去重策略，实际上真实业务场景中也应该慎用。因为极端场景去重失效的过程中会有不断重复消费被状态卡住的日志告警，研发人员是有好几个小时的机会进行人工介入处理的。