RocketMQ 消息去重操作及幂等性设计

RocketMQ之去重操作 在讨论RocketMQ的去重操作时，需要首先了解RocketMQ的设计理念，即不考虑消息去重的问题，将这个问题抛给业务端自己去处理幂等的问题。因此，作为RocketMQ的使用者，需要自己通过某些方式去保证消息去重。 RocketMQ本身是否提供某些关键信息可以帮助我们去重？从业务上支持幂等的角度来看，RocketMQ不支持消息去重的问题，可以通过设计一层db来解决业务幂等问题，例如通过记录订单id来唯一标识一条消息。这样可以带来严重的吞吐量下降问题。 在设计业务幂等的解决方案时，需要考虑消息的状态，例如NONE、SUCCESS、PROCESS、ERROR等。然后，通过这些状态来设计一个严谨的业务幂等的解决方案。但是，这样做可能会导致整个吞吐量下降非常多，一条消息的消费至少涉及三次db操作，其中两次dbwriter。 在系统架构引入消息队列时，需要解决的问题包括解耦、提高响应速度、流量削峰填谷、数据异构等。特别是在消息的消费速度远远低于生产者的生产速度时，会造成大量的消息堆积，带来的影响是非常严重的。 通过一致性方案、消息去重等方法可以减轻如果组件方突然出事故的情况所带来的生产事故。例如，不通过业务上的各种唯一id来处理消息去重问题，而是基于原先对于RocketMQ的了解，下意识去考虑RocketMQ中的MsgId是否可以作为去重的关键点？具备去重最紧要的首要因素是——>该值可以全局唯一的标识一条消息。 在单机环境下想要生成唯一id是一件非常容易的事，比如通过snowflake算法生成唯一id。但是在分布式环境下，生成唯一id变得非常复杂，需要考虑到分布式环境下的唯一id生成问题。 RocketMQ之去重操作需要从业务上支持幂等的角度来看待，通过设计一层db来解决业务幂等问题，并考虑到消息的状态和唯一标识问题。同时，需要解决系统架构引入消息队列时的各种问题，并减轻如果组件方突然出事故的情况所带来的生产事故。