Kafka双生产者架构下重复事件投递问题的最优解决方案咨询

可选替代方案如下： #

1. 生产者主备切换模式 #

• 无需引入Akka这类重型分布式组件，仅需基于轻量分布式锁（可基于ZooKeeper、Redis，甚至Kafka自带的__consumer_offsets主题实现），让两个生产者同一时间仅一个处于激活状态，另一个作为热备节点
• 激活节点故障时，备节点自动抢锁接管生产任务，既保留了原架构的高可用能力，又从根源上避免了重复事件生成
• 实现成本极低，无需改造下游消费逻辑，也不需要生产者之间做复杂的数据同步

2. Kafka Streams中间层轻量去重 #

• 在生产者和最终消费者之间新增一层无状态Kafka Streams处理任务：
  • 首先给每个事件绑定全局唯一的业务幂等键（比如外部回调的请求ID、事件本身的唯一标识字段），将该键设为Kafka消息的Key
  • 配置流处理任务的窗口去重逻辑，根据两个生产者的消息发送最大时间差设置合理的去重窗口（通常几十秒即可覆盖绝大多数场景），同一个幂等键在窗口内仅保留第一条消息
  • 去重后的消息写入新的Bla_dedup主题供下游消费者订阅，原有生产者、消费者逻辑几乎不需要改造，仅新增一个轻量流处理任务，运维成本很低

3. 消费侧独立去重层 #

• 不需要改造生产者，也不需要修改原有消费业务逻辑实现幂等，在消费逻辑前新增独立的去重校验层：
  • 采用低成本KV存储（比如Redis、本地RocksDB）存储已经消费过的事件唯一标识，根据业务上重复事件可能出现的最大时间跨度设置合理的过期时间
  • 消费者拉取到消息后先查询KV存储，若标识不存在则执行实际消费逻辑，同时将标识写入KV存储；若已存在则直接跳过该消息
  • 特别适合消费业务逻辑复杂度高、改造幂等成本较高的场景，去重逻辑和业务逻辑完全解耦

4. Broker侧日志压缩去重 #

• 如果你的Kafka集群版本支持，可将每个事件的全局唯一标识设为消息Key，将Bla主题的log.cleanup.policy配置为compact，同时调整合理的delete.retention.ms参数
• Broker会自动对同一个Key的消息做日志压缩，保留最新的一条同Key消息，消费者拉取时不会拿到同Key的重复消息
• 该方案仅适合对消息投递实时性要求不高、重复消息发送间隔大于日志压缩触发间隔的场景

内容的提问来源于stack exchange，提问作者paul