Kafka重试事件应由Consumer还是服务端负责生产？

场景背景 #

我们有一个Kafka消费者从高负载的普通Topic拉取事件，每个事件都需要调用耗时不稳定的服务端接口，同时设有重试Topic用于处理接口调用失败的情况。核心问题是由哪个角色负责生成重试事件，现有方案各有明显短板，需要找到既能避免consumer lag，又能保证所有失败事件都有重试机会的高韧性方案。

现有方案的问题分析 #

• 消费者生成重试事件：必须等待接口调用完成后才能决定是否生成重试事件，处理速度被接口耗时拖慢，在高负载场景下极易引发consumer lag，甚至导致消费堆积
• 服务端生成重试事件：消费者可以实现“发送即遗忘”，彻底规避消费延迟问题，但如果服务端生成重试事件失败（比如Kafka生产超时、网络故障），这条失败事件的重试记录会永久丢失，无法挽回
• 新增DB存储重试事件：本质和Kafka生产失败的风险一致，DB写入失败时同样会丢失重试记录，没有从根本上解决可靠性问题

高韧性解决方案：异步分层+双重保障 #

1. 消费者侧：异步解耦，快速提交偏移量 #

消费者拉取事件后，不直接同步调用服务端接口，而是将事件投递到本地异步任务队列（如基于Disruptor的内存队列）或轻量分布式任务队列，随后立即提交Kafka偏移量。这样消费者的处理速度完全不受接口耗时影响，从根源上避免consumer lag。

2. 重试事件生成：双重写入，兜底重试 #

异步任务负责调用服务端接口，当调用失败时：

• 优先使用Kafka同步生产+acks=all配置发送重试事件，确保生产请求得到所有ISR副本的确认，同时开启Kafka幂等性，避免重复生成重试事件
• 如果Kafka生产失败（如网络波动、集群不可用），立即将重试事件写入本地持久化存储（如RocksDB、本地磁盘文件），并为事件添加唯一标识和重试时间戳
• 启动后台定时任务，定期扫描本地存储中未成功发送的重试事件，按照重试时间戳依次重新发送到重试Topic，发送成功后删除本地记录

3. 重试链路兜底：死信Topic+监控告警 #

• 为重试Topic设置重试次数上限，当事件重试次数达到阈值后，转入死信Topic，避免无限重试阻塞队列，同时便于人工介入排查根因
• 配置监控告警：针对consumer lag、重试Topic堆积量、本地存储未发送事件数量设置告警规则，及时发现并处理异常

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