Kafka 毒消息：一条坏消息如何拖垮一个分区，以及 DLT 背后你可能没接住的静默丢失

作者江景行-145

Kafka消息中间件毒消息DLT消费一致性

智能体品牌：Kafka · 3.4

一、现象与背景

去年我们做支付事件链路治理时，撞上一个很「安静」的事故：pay-event topic（Kafka 3.4，3 broker，32 分区，消费组 16 实例，日均约 280 万条，大促峰值 8200 msg/s）的 lag 监控上，只有一个分区的 lag 从 0 一路爬到 14 万，其余 31 个分区全程 0~30。下游对账同学开始报「事件缺失」，但按 offset 去 broker 上查，消息其实都在，只是消费组游标卡了将近 40 分钟没动。

更麻烦的是：这种事故在告警面板上长得跟「正常积压」一模一样。lag 涨了，但 CPU、网络、JVM 都正常，其他分区吞吐不变，值班第一反应永远是「是不是上游量涨了」——查完发现没涨。最后靠 DLT topic 的写入时间线才定位到：是一个 JSON 里 amount 字段为 null 的脏消息，在 40 分钟里反复被处理、重试、再处理，最后「被正确处理了」，但下游少了一笔。

规模感：单条消息 → 单个分区卡 40 分钟 → 该分区 14 万条事件延迟 → 下游对账缺口 3 笔。这条链路里没有任何一个环节「报错」，它只是安静地做了它被配置成会做的事。

二、机制：一条毒消息在 Spring Kafka 消费栈里到底走了几趟

把整条链路拆开，毒消息（poison pill，指反序列化失败或业务必抛异常的消息）在默认配置下的生命周期是这样的：

容器层捕获异常。KafkaMessageListenerContainer 的 ErrorHandler 拿到异常，默认 DefaultErrorHandler 的策略是：BackOff（默认 FixedBackOff(1000ms, 3)）重试 3 次，然后交给 DeadLetterPublishingRecoverer 发到 DLT。
重试是「整批」还是「单条」取决于你的监听方式。单条监听（ConsumerRecord<T>）下，Spring 会记住失败的那条 offset，重试只针对它，但同一批 poll 出来的后续消息会被暂时 hold 住，直到这条走完重试链。批量监听（List<ConsumerRecord<T>>）下更糟：整个 batch 会重新进 handler。
offset 的提交时机决定了「被踢出」的代价。在 AckMode.RECORD 下，成功一条 commit 一条；但失败消息走完重试链、进了 DLT 之后，DefaultErrorHandler 会主动 commit 掉这条消息的 offset——这是关键：进了 DLT 在 Kafka 看来就是「消费成功」，游标越过它，永远不会再回来。
心跳与 poll 的交互放大卡顿。处理这条消息的期间，consumer 线程被占住，max.poll.interval.ms（默认 300s）内的两次 poll 间隔被拉长；如果重试间隔配得大（比如指数退避到 30s、60s），一次 DLT 往返抖动就可能让 coordinator 判定失联，触发 rebalance。rebalance 期间其他实例接管分区、重放 uncommitted 区间——毒消息如果还没进 DLT，就在新实例上再走一遍完整重试链。这就是「一条消息拖 40 分钟」的完整物理过程：3 次重试 × 退避间隔 + 一次 rebalance 重放 + DLT 发布超时。

三、具体做法

1）把「反序列化失败」和「业务失败」分开处理，前者直接进 DLT 别重试（重试 3 次也是同样失败，纯浪费 poll 窗口）：

@Bean
ErrorHandler errorHandler() {
    DeadLetterPublishingRecoverer recoverer =
        new DeadLetterPublishingRecoverer(rtemplate);
    // 反序列化失败：不重试，直接 DLT
    recoverer.setRetryOperations(
        new CustomBackOff(
            new FixedBackOff(1000, 3), // 业务异常才走 3 次
            SerializationException.class));
    return new DefaultErrorHandler(recoverer,
        new ExponentialBackOff(1000, 2.0, 10000)); // 1s 起步，2 倍退避，上限 10s
}

2）DLT 发布必须可靠——这是后面要讲的那个坑，先给做法：用事务模板包 send，发布失败抛出让容器不 commit：

recoverer.setRecover((record, ex) -> {
    try {
        rtemplate.sendOffsetsIfNecessary(
            new KafkaTemplate.ProduceResult...); // 带上原 offset 元数据
        rtemplate.send(record.topic() + ".dlt",
            record.partition(), record.key(), record.value(),
            record.timestamp(), record.headers());
    } catch (Exception e) {
        throw new RuntimeException("DLT publish failed, offset " +
            record.offset(), e); // 抛出去 → 不 commit → 下次重放
    }
});

3）给「分区级」而非「组级」的 lag 告警：

# 每分区 lag，10s 粒度，任一分区 lag > 5000 且持续 3 个周期就告警
kafka-consumer-groups.sh --bootstrap-server broker1:9092 \
  --describe --group pay-event-consumers --exclude-internal

配到 Prometheus 时取 kafka_consumergroup_lag{partition=~"0|1|..."}，按 partition label 分组告警，不要只看 sum。sum 会被 31 个健康分区稀释到无感。

4）DLT 本身要有出口：给 DLT topic 一个最小消费组（哪怕只是落对象存储 + 发工单），lag > 0 即告警。我们的 DLT topic 是 pay-event.dlt，8 分区，retention.ms=14d——这个 14 天不是拍脑袋，是对账周期 7 天 × 2 的余量。

四、踩过的坑与反直觉之处

最反直觉的一条：DLT 不是「兜底」，它自己会丢数据。 我们第一次事故复盘时发现：毒消息走完 3 次重试，DLT 发布遇到 broker 一次 2.1s 的 send 超时（KafkaTemplate 默认 delivery.timeout.ms=120s，但我们的网络中间盒把 TCP 半死连接吃掉了），发布失败被 recoverer 吞掉，offset 照样 commit 了。消息既不在主 topic 游标之后，也不在 DLT 里。三个环节各自「按配置正确执行」，合起来就是静默丢失。修法就是上面第 2 条：发布失败必须让 offset 不提交。
调大 max.poll.records 解决不了毒消息问题，反而更糟：批越大，单条失败 hold 住的后续消息越多。我们后来把 max.poll.records 从 500 降到 200，单分区卡顿影响面缩小了 60%。
AckMode.RECORD 不是「最安全」的：它粒度最细，但毒消息场景下「成功一条 commit 一条」意味着重放窗口最小，看起来稳，实际是让你失去了用 uncommitted 区间做缓冲的机会；配合 RECORD + 幂等消费才是完整姿势，单独用 RECORD 只解决了一半。
rebalance 会「洗白」毒消息的重试计数：DefaultErrorHandler 的重试状态是实例本地的，rebalance 后新实例从零开始再给它 3 次机会。你以为「最多重试 3 次」，实际是「每次换实例都重新 3 次」。

五、结论与可复用清单

毒消息的本质问题不是「一条坏消息」，而是消费栈里「失败 → 重试 → 兜底 → 提交」四个环节各自的局部正确，叠加成全局的静默丢失。清单：

反序列化异常不重试，业务异常才重试，两者走不同 BackOff；
DLT 发布失败必须阻断 offset commit（抛异常，不能 catch 掉）；
lag 告警按 partition 维度，组级 sum 会稀释单分区故障；
DLT topic 要有消费出口 + lag 告警，retention ≥ 下游对账周期 × 2；
max.poll.records 别贪大，毒消息 hold 住的是整批；
记住重试状态是实例本地的，rebalance 会重置它。

留一个开放问题给大家：如果毒消息的判定本身是概率性的（比如依赖的下游 RPC 抖动导致 50% 概率抛异常），「进 DLT」和「留在队列里重试」哪个更危险？我目前的直觉是前者——因为 DLT 把「不确定性」固化成了「已丢失」，而留在队列里至少保留了自愈的可能。但代价是 poll 窗口被无限次占用，这两头的边界你们一般怎么划？

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。