面试题：消息队列RocketMQ中消息去重与防重复消费的底层原理及优化策略

生产者端去重：
- RocketMQ 生产者在发送消息时，如果开启了去重功能（enableMsgTrace 且 customizedTraceTopic 配置），会生成一个唯一标识 msgId。这个 msgId 是基于消息体、生产者 IP 等信息生成的 hash 值。
- 当消息发送到 Broker 时，Broker 会根据这个 msgId 检查是否已经存在相同的消息。如果存在，则不再重复存储该消息。在 SendMessageProcessor 类的 sendMessage 方法中，会有类似如下逻辑：

if (messageStore.isDuplicateMessage(msgId)) {
    // 处理重复消息逻辑
} else {
    // 正常存储消息逻辑
}

消费者端去重：
- 消费者端利用 offset 来辅助去重。消费者在消费消息时，会记录当前消费的 offset。如果发生重复消费，由于 offset 是有序递增的，相同 offset 的消息可以被识别为重复消息。
- 另外，消费者可以结合业务自身的幂等性设计来确保重复消费不会产生副作用。例如，业务操作如果是数据库插入操作，可以使用唯一索引，若重复插入相同数据会因为唯一索引冲突而失败，从而达到幂等效果。

Offset机制：
- RocketMQ 的 Consumer 会维护一个消费进度 offset，Consumer 每次从 Broker 拉取消息时，会带上这个 offset。如果发生重复消费，Consumer 拉取到的消息 offset 是之前已经处理过的，Consumer 可以通过记录已处理的 offset 来判断并丢弃重复消息。
- 在 DefaultMQPushConsumerImpl 类的 processMessage 方法中，会处理消息消费逻辑，其中会涉及到 offset 的更新和管理。在消费消息前，会检查当前 offset 是否已经处理过，避免重复消费。
幂等性设计：
- RocketMQ 本身不直接提供完全的幂等消费保证，但提供了一些机制辅助实现幂等。例如，消息的 msgId 可作为幂等标识。业务在消费消息时，可以先根据 msgId 检查是否已经处理过该消息。
- 对于写操作，如数据库更新，可以采用 UPDATE ... WHERE condition AND version = oldVersion 的方式，通过版本号机制实现幂等，确保重复消费不会多次更新数据。

优化方向一：增强 Broker 端去重能力
- 优化方案：
  - 在 Broker 端采用更高效的数据结构存储已接收消息的 msgId，如布隆过滤器（Bloom Filter）。布隆过滤器可以在占用较小内存空间的情况下，快速判断一个 msgId 是否存在。
  - 当 Broker 接收到新消息时，先通过布隆过滤器检查 msgId，如果布隆过滤器判断 msgId 不存在，则进一步检查实际存储（如内存哈希表），如果确实不存在则存储该消息。
- 预期效果：
  - 减少 Broker 端去重时的内存占用，提高去重效率，尤其是在高并发消息场景下，减少判断重复消息的时间开销，提升整体消息处理性能。
优化方向二：消费者端自动幂等处理
- 优化方案：
  - 在 RocketMQ 的 Consumer 层面提供一个通用的幂等处理框架。例如，定义一个注解（如 @Idempotent），消费者业务代码方法上添加该注解后，Consumer 框架自动处理幂等逻辑。
  - 框架可以通过维护一个本地缓存（如 Guava Cache）来记录已处理消息的 msgId，在处理消息前先检查缓存，若已处理则直接返回成功，不再执行具体业务逻辑。
- 预期效果：
  - 降低业务开发者实现幂等的成本，使消费者端幂等处理更加标准化和便捷。提高消费者处理消息的可靠性，避免因业务开发者疏忽未实现幂等导致的重复消费问题。

星途面试题库