RocketMQ是大型架构的核心，下面我重点详解RocketMQ重复消费方案@mikechen
幂等消费（消费端实现）
在分布式消息系统中，消息重复消费是常见且棘手的问题，可能导致数据不一致。
采用幂等性，是应对重复消息最直接且推荐的做法。
消费者在处理消息时，确保相同的消息多次处理结果不变。
常见实现方式包括：
使用业务唯一标识，如订单号、事务ID，作为幂等键。
在数据库或缓存（如Redis）中记录已处理标识，重复到达时直接忽略；
在数据库写操作使用“INSERT … ON DUPLICATE KEY”或唯一索引、防止重复写入；
优点：业务侧控制，通用且可靠。
缺点：需要设计幂等逻辑并维护状态存储。
事务消息（RocketMQ 事务消息机制）
RocketMQ 支持分布式事务消息，发送方在发送半消息（prepare）后执行本地事务，根据本地事务结果提交或回滚消息。
Broker 会在超时后回查发送方以确定最终状态。
适用场景：需要严格保证消息与本地业务操作一致性的场景（例如订单创建与消息发布必须原子化）。
优点：将消息状态与本地事务关联，能降低重复消费概率。
缺点：实现复杂，回查机制可能增加延迟和系统耦合。
消息去重（Broker/中间层或消息ID校验）
在消息进入消费流程前进行去重校验，常见方法有：
在消费者或前置网关处维护近期消息ID集合（如布隆过滤器、Redis SET）以判断消息是否已处理；
使用RocketMQ消息的MessageId或应用层自定义ID作为唯一标识进行校验；
优点：可以在消费前快速过滤重复消息，减轻后端压力。
缺点：需要额外存储与过期策略，并处理误判（例如布隆过滤器误判带来的误拒）。
精确一次语义与事务补偿设计
虽然实现完全的“精确一次”（exactly-once）通常代价高昂，但可以通过架构设计与补偿机制接近其效果：
采用幂等写+事务/补偿流程：在消费者处理失败或重试后，通过补偿事务或补偿消息修正数据；
将消息处理与状态变更放入同一持久化事务（例如借助外部协调器或分布式事务管理器），确保处理与状态一致；
优点：能在复杂业务中保证最终一致性。
缺点：实现复杂，性能与复杂度权衡明显。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号，获取更多技术干货！
后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》