在Java面试中，关于消息队列如何防止消息被重复消费的问题，可以从以下几个方面进行回答，结合系统架构设计、消息队列机制和业务逻辑处理，确保在不同场景下实现消息的幂等性。
1. 消息队列重复消费的根本原因
消息重复消费的根本原因通常包括以下几种情况：
- 消费者在处理完消息后未能成功向消息队列（MQ）发送确认（ack）。
- 网络问题或MQ服务重启导致确认丢失，MQ认为消息未被成功消费，从而重新投递。
- 消费者在处理消息时发生异常或宕机，导致未及时确认消息。
2. 防止消息重复消费的常见策略
2.1 业务层幂等性设计
这是最通用也是最核心的解决方案。即使消息被重复消费，业务逻辑也能保证最终状态一致。常见做法包括：
- 使用唯一业务ID（如订单ID）结合数据库唯一索引或Redis缓存进行去重判断。
- 在处理消息前先检查是否已执行过该操作，例如通过状态机机制控制订单状态流转。
- 使用数据库乐观锁更新数据，确保并发操作不会造成数据错误。
2.2 消息队列手动确认机制
对于支持手动确认的消息队列系统（如RabbitMQ），消费者应在处理完消息并确保业务逻辑成功执行后，再向MQ发送ack确认。这样可以避免消息在处理失败时被误认为已消费。
2.3 生产者唯一ID + Broker端去重缓存
可以在消息发送时为每条消息分配唯一ID（如UUID或业务ID），Broker端维护一个去重缓存（如Redis），记录已处理过的消息ID。当接收到相同ID的消息时，直接丢弃或跳过处理。
2.4 消费者本地去重
消费者端可以使用本地缓存或数据库记录已消费的消息ID，在每次消费前先检查是否已处理过该消息。这种方式实现简单，但需要考虑缓存清理策略和数据一致性。
3. 不同消息队列系统的处理方式
3.1 RabbitMQ
- 使用手动确认机制（manual acknowledgment），确保只有在消息被正确处理后才从队列中删除。
- 配合唯一ID机制，在消费者端进行幂等处理。
3.2 Kafka
- Kafka本身不提供去重功能，但可以通过以下方式实现：
- 使用Kafka的offset机制，结合外部存储（如MySQL、Redis）记录消费进度。
- 每条消息携带唯一ID，在消费时进行幂等校验。
- 使用Kafka事务机制（Kafka 0.11+）来实现精确一次（exactly once）语义。
4. 代码示例：幂等消费逻辑
以下是一个基于Redis缓存消息ID实现幂等性的Java代码片段：
public void consumeMessage(String messageId, String businessData) {String redisKey = "consumed_message:" + messageId;Boolean isProcessed = redisTemplate.hasKey(redisKey);if (Boolean.TRUE.equals(isProcessed)) {// 消息已处理，跳过return;}try {// 执行业务逻辑processBusinessData(businessData);// 标记消息为已处理redisTemplate.opsForValue().set(redisKey, "processed", 1, TimeUnit.DAYS);} catch (Exception e) {// 记录日志并处理异常log.error("消息处理失败", e);}
}
