Lag 很高时，问题可能发生在哪

验证：制造一个真实比生产慢3倍的consumer

命令 · python # producer真实每1毫秒发一条 p.produce(TOPIC, value=str(i).encode()) time.sleep(0.001) # consumer真实每处理一条sleep 3毫秒(模拟处理逻辑比较重) m = c.poll(0.1) if m: time.sleep(0.003)

验证：LAG真实不是一个静态数字，是持续爬升的

真实实测 · 本机执行输出(每3秒采样一次kafka-consumer-groups.sh)

t=3s:  CURRENT-OFFSET=1614   LOG-END-OFFSET=7225   LAG=5611
t=6s:  CURRENT-OFFSET=4087   LOG-END-OFFSET=14753  LAG=10666
t=9s:  CURRENT-OFFSET=6689   LOG-END-OFFSET=22185  LAG=15496
t=12s: CURRENT-OFFSET=9301   LOG-END-OFFSET=29789  LAG=20488
t=15s: CURRENT-OFFSET=11909  LOG-END-OFFSET=37394  LAG=25485
t=18s: CURRENT-OFFSET=14528  LOG-END-OFFSET=44926  LAG=30398

真实关键的诊断信号不是LAG的绝对值大小，是它随时间持续增长这个趋势——18秒里LAG真实从5611涨到30398，涨了约5.4倍，而且看不出任何收敛的迹象。这种模式真实指向一个结构性问题：consumer的处理速度天生比生产速度慢，不管等多久LAG都只会越滚越大，不会自己恢复。如果LAG只是短暂冲高然后真实回落，通常是consumer刚重启还在追赶历史数据，或者生产端出现了短暂的流量尖峰——这两种情况真实不需要紧张；但持续单调上涨，通常真实意味着要么consumer处理逻辑效率有问题(本例这种)，要么consumer实例数量真实不够分摊分区，要么下游依赖(数据库、外部API)变慢拖累了整个处理链路。

分步演示：LAG真实的增长曲线

每一步都是本文上面每3秒真实采样一次得到的原始结果。

LAG持续单调上涨，是consumer处理能力不够的真实信号

这一步新采样的LAG

参考与说明

数据来自本机3节点Kafka 4.3.1集群，topic lagtrouble-demo，生产节奏1毫秒/条，consumer人为处理延迟3毫秒/条。
和《Consumer Lag 到底怎么算》一起看：那篇给出LAG的静态计算公式，这篇看它作为一个随时间变化的指标真实怎么暴露问题。
没有验证：真实生产环境里consumer处理慢的具体原因(数据库慢查询、GC停顿、下游限流)哪一种更常见；增加consumer实例数量后LAG真实的恢复速度。

下一篇 · KAFKA 内部原理 60

Broker 参数：分区数、Segment 大小和保留策略