Kafka生产者如何实现幂等性(3大解决方案)

Kafka是大型架构核心，下面我详解Kafka生产者如何实现幂等性@mikechen

Kafka幂等生产者

Kafka通过在生产者端启用幂等，设置 enable.idempotence=true。

properties.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true");  // 核心开关
properties.put(ProducerConfig.ACKS_CONFIG, "all");                 // 必须 all，确保持久化
properties.put(ProducerConfig.RETRIES_CONFIG, Integer.MAX_VALUE); // 重试次数最大
properties.put(ProducerConfig.MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION, 5); // 最大 5（有序保证）

生产者，会为每个会话维护一个Producer ID（PID）和递增的序列号（sequence number）。

Broker端利用PID、和序列号，检测并丢弃重复的分区写入请求。

从而，实现单个生产者会话内对同一分区的消息“最多一次”投递保证。

优点：是透明、延迟低且无额外存储。

缺点：是仅在单个producer会话有效，适合大多数需要单机/单会话幂等的场景。

 

事务（Transactions）

虽然启用 Idempotence Producer ，可以保障单分区写入的幂等性。

但它无法解决：跨分区操作或跨会话（生产者重启）的幂等性、及原子性问题。

如果你不仅要“去重”，还要：

跨分区幂等；

多 Topic 原子写；

Exactly Once 语义；

需要使用 Kafka 事务。

缺点：是复杂度增加、性能开销上升（事务协调器参与）、并发场景下事务冲突需重试。

 

外部去重（应用层幂等设计）

当内置幂等或事务，无法满足业务需求时，可在应用层引入外部去重机制。

比如：

定义业务唯一 ID (Business Key): 在消息体中嵌入一个对业务具有唯一性的 ID（例如：订单 ID、请求 ID、操作流水号）。

使用外部存储： 消费者在处理消息之前，先查询一个外部存储（如 Redis 或数据库）。

此方案灵活且与Kafka版本无关，能处理复杂的跨进程、跨服务重复问题。

缺点是需要额外存储与一致性设计，可能带来性能和运维成本。

mikechen睿哥

10年+一线大厂架构实战专家，就职于阿里、淘宝等一线大厂，操盘多个亿级大厂核心项目。