一个 Kafka topic 堵了 几个小时监控全绿、没有任何报错

故障现象——痛点一：业务卡死却没有任何告警

一个 Kafka topic 被堵住数小时后续排队的活动全部无法上线；监控面板依旧绿灯，告警程序毫无响应。说起来，

• 没有异常日志、没有堆栈、没有超时信息。
• 数据库里对应活动模板的状态字段显示已部署看似一切正常。
• 实际情况是的观点是。活动根本没上线，整个程序陷入“假象健康”。

后来发现，问题源于三个相互叠加的设计缺陷。如果你的服务中也有“在 Kafka 使用者里干重活”的代码，请对照以析逐一核查。其实，

至于第一坑，状态是“已完成”。并不代表工作已经结束

场景复盘：

活动模板的部署流程分两步：

1. 把模板状态改为已部署。
2. 对受影响的所有使用者进行批量开关操作，可能涉及上百万使用者。不过，

这两步写在同一个方法、同一个线程里且中间没有 return

void activateCampaignTemplate {
deployTemplate;// 第①步：改状态为“已部署”，秒级
processAffectedUsers;按理说，// 第②步：百万使用者逐个处理。可能耗时数小时
}

痛点：

• "已部署"仅代表第一步先完成；接下来仍在后台耗时运行，
• 运维人员只看到数据库字段为已完成，就误判任务已结束。
• 实际线程仍卡在第②步，对每个使用者同步调用下游接口。话说回来，

至于第二坑。同步逐条远程调用导致耗时指数级增长

主要代码示例：

for {
feign.queryKycLevel;其实，// 同步阻塞
feign.queryUserDetail;// 同步阻塞
// ，每个使用者多次远程调用。全程串行
}

痛点表现：

• 普通活动影响几百或几千使用者时仅耗数秒，可接受。
• 当使用者规模膨胀至上百万时同步串行调用导致整体耗时从秒级飙升至数小时。
• 每一次调用都成功返回。只是慢到累积成灾难，没有错误抛出。

The deployment trigger is a Kafka topic configured with only **1 partition** and **1 consumer thread**.

• Pain point: 单分区天然缺乏消息隔离性——只要当前消息未处理完，后续所有消息都必须排队等待。
• The massive “million‑user” message becomes a traffic jam on a single‑lane road,blocking every subsequent activity launch.
• This explains *** impact was not limited to a single campaign but manifested as a **global service outage**.

#4 rebalance 不是安全网。而是二次伤害

Kakfa 会在使用者超过 `max.poll.interval.ms` 未调用 `poll` 时将其踢出消费组并触发 **rebalance**。在本案例中的观点是，

• 该条巨型任务耗时远超阈值。broker 已将使用者标记为失活并重新分配分区。怎么说呢，
• 任务结束后尝试提交 offset 时发现自己已经被踢出组。提交失败导致 offset 回退。
• 于是同一条巨型任务被 ** 消费**。若去重键未覆盖所有业务维度，则会产生真正的重复执行。

Pain point: 如果忽视 max.poll.interval.ms 的影响，你会把一次慢任务变成 无限循环 的灾难。

#5 修复思路——先止血，再根治。最终升级架构

① 应急止血

• 直接在数据库把卡住、重复的模板标记为「拒绝」或「已取消」，解除阻塞，让后续活动恢复排队执行。

② 根治同步批处理

• 将 **逐使用者同步调用** 完全迁移到独立线程池或异步任务队列；使用者线程只负责快速确认收到消息并立即返回。
• 为单条消息设置超时时间；超时后主动提交 offset 并发送告警，防止单条慢消息拖死 poll 循环。
• 接受业务上的权衡：状态显示 “已部署” 不再等价于 “所有使用者已迁移完成”，从准实时转为 **异步最终一致**。

③ 架构升级

• 把带副作用的消费逻辑从定时批处理改为 Kafka 原生流式消费。并基于业务 key 做水平分片，实现 **同业务实体有序、不同实体并行**。
• 从关键原则来看。
  1. 仅保序到业务实体粒度，而非整个分区；
  2. offset 必须按连续完成区间提交，并配合 DLQ 防止“毒丸”消息永久卡死；
  3. 所有副作用必须幂等，因为重复消费不可避免。其实，
• 长期方案是 分区数量。让生产侧按业务 key 路由、消费侧按 partition 并行，这才是真正遵循 Kafka 原生模型的做法。

#6 Kafka 消费卡死的一步步排查清单

1. Step 1 – 判断是 “卡住” 还是 “未收到”。

   kafka-consumer-groups.sh --bootstrap-server  \
   --describe --group 
   

   查看 LAG 与 CURRENT-OFFSET：
   • LAG 继续增长而 CURRENT-OFFSET 不动 → 消息进入但使用者停滞。
   • 两者均不动 → 需检查生产端是否正常发送。
2. Step 2 – 检查消费组成员是否仍存活。 同一命令输出中观察 CONSUMER‑ID 与 HOST。如果分区 owner 为 *empty* 或组状态频繁在 *PreparingRebalance / CompletingRebalance* 循环。则说明使用者被踢出组，多半是因为单条消息处理超时。
3. Step 3 – 别只信数据库状态字段，用 jstack 抓线程栈定位真实阻塞点。

   jstack > /tmp/stack1.txt
   sleep 5
   jstack > /tmp/stack2.txt
   diff /tmp/stack1.txt /tmp/stack2.txt | grep -i "Consumer"
   

   找到长时间停留在业务方法中的消费线程，即可确认它仍在处理首条消息而未返回。怎么说呢，
4. Step 4 – 粗算最坏耗时并对比 max.poll.interval.ms。说起来， 统计该方法对单条消息需执行多少次远程调用或 DB 操作。用当前最大数据量乘以单次耗时得到理论上限。如果大于配置的 `max.poll.interval.ms`。则必然触发 rebalance，是根本原因之一。
5. Step 5 – 核实幂等去重键是否覆盖全部业务维度。 检查去重实现是否仅基于部分字段，例如只用 activityId 而忽略了 userId 或 batchId。出现真正意义上的二次执行。

• **状态字段不是完成标志**：它只能说明代码执行到了哪一行，后面可能还有耗时数小时的同步逻辑。不要仅凭 DB 中 “已完成” 就认为业务已经落地。话说回来，
<
• **Kafka 使用者里干重活前必须预估最坏执行时间**：数据量翻倍代表着执行时间也可能翻倍。一旦超过 `max.poll.interval.ms` 就会引发 rebalance 与重复消费风险。不过，**单分区缺乏隔离性**：一条慢消息会把整条链路堵死；当业务规模扩大到“单条消息可能很重” 时需要重新评估 partition 策略或采用并行消费模型。

If you suspect any of your Kafka consumers are silently choking on a “normally fast but potentially hours‑long” message,follow checklist above and you’ll be able to pinpoint root cause before it turns into an 18‑hour silent outage.