Kafka是大型架构核心，下面我详解Kafka消息重复消费方案@mikechen
幂等生产
启用 Kafka 的幂等生产者功能（idempotence），可确保生产端即使重试也不会产生重复写入。
enable.idempotence=true
幂等生产为每个生产者分配序列号并在 broker 端去重，适用于源头可能重试发送消息的场景。
该方案主要解决生产端重复产生的问题，但对消费者侧的重复处理无直接保障。
事务性写入
利用 Kafka 事务（Transactional API），可实现“全有、或全无”的消息写入流程。
transactional.id=xxx
适合需要跨分区、或跨主题原子性保证的场景。
生产者在事务中提交消息后，消费者可以使用 read_committed 模式读取。
避免读取到未提交、或中间状态造成的重复或半成品数据。
事务机制能显著提高一致性，但会带来一定的性能与实现复杂性开销。
消费端去重
在消费者端通过唯一标识（如消息 ID、业务唯一键或幂等 token）做去重。
常见实现包括：
将已处理的消息 ID 写入外部持久存储（如数据库、Redis、RocksDB。。。）,并在消费前检查；
使用本地状态存储（如 Kafka Streams 的 state store）跟踪已处理记录；
基于时间窗口的短期缓存去重以降低存储成本。
此方案对任意来源的重复都有效，但需权衡存储一致性、性能和数据保留策略。
精确一次处理
结合 Kafka 事务、幂等写入与外部系统的事务。
例如：使用两阶段提交、或幂等外部写入，构建端到端的“精确一次”语义。
Kafka Streams 和 Kafka Connect 提供的工具可简化部分实现。
E2EP 是最严格的保证，能最大限度消除重复处理风险。
但实现复杂、性能开销相对较高，且对外部系统支持要求较高（需支持幂等写入或参与分布式事务）。
mikechen睿哥
10年+一线大厂架构实战专家，就职于阿里、淘宝等一线大厂，操盘多个亿级大厂核心项目。