Kafka运维与积压排障#

一句话答案#

Kafka 运维核心看 Consumer Lag（消费延迟）、ISR 收缩（broker 健康）、磁盘/网络 IO（性能瓶颈）；积压排障三板斧：扩消费者并行度、跳过堆积消息、修复消费端瓶颈（DB慢查询/外部调用超时）。

核心要点

一、关键运维指标

指标	含义	获取方式	告警阈值
Consumer Lag	未消费消息数	`kafka-consumer-groups.sh --describe`	>10000 或持续增长
ISR 收缩	副本同步落后	`kafka-topics.sh --describe`	ISR < replicas
Under-Replicated Partitions	未完全同步的分区	JMX: UnderReplicatedPartitions	>0
Active Controller Count	活跃 Controller 数	JMX（全集群求和）	≠1
Request Queue Size	请求队列长度	JMX: RequestQueueSize	持续增长
Disk Usage	磁盘使用率	系统命令	>70%
Network In/Out	网络吞吐	JMX: BytesInPerSec/BytesOutPerSec	接近带宽上限

二、Consumer Lag 排查 SOP

# 1. 查看消费组 lag
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --describe --group my-group

# 输出：
# TOPIC    PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG
# my-topic 0          1000            5000            4000  ← lag=4000

# 2. 判断 lag 趋势
# lag 稳定 → 消费速率=生产速率，只是有延迟
# lag 持续增长 → 消费跟不上，需要扩容或修复

# 3. 定位消费端瓶颈
# 常见原因：
# a) 消费逻辑慢（DB查询/外部调用/序列化）
# b) 消费者数 < 分区数（有分区无人消费）
# c) 消费者频繁 rebalance（session.timeout/heartbeat 配不对）
# d) 消费端 GC 频繁

bash

三、积压紧急处理方案

方案	适用场景	操作
扩消费者	消费者数<分区数	增加消费者实例（不超过分区数）
临时扩分区	消费者=分区数仍积压	增加分区+增加消费者（注意有序性影响）
跳过积压	旧消息不重要	`kafka-consumer-groups.sh --reset-offsets --to-latest`
转储到其他topic	需要快速消费但处理慢	消费者只转发不处理，另建慢消费者处理
修复消费瓶颈	DB慢/外部超时	优化慢查询/增加超时/降级/批量处理

四、积压对 Broker 的连带影响（PageCache 被打穿）

Kafka 快靠顺序写 + PageCache + 零拷贝（原理见 Kafka高性能原理）。积压时要注意：

严重积压的消费者读的是早已被挤出 PageCache 的冷数据，只能走磁盘读，Broker 磁盘 IO 飙升。
冷读会把 PageCache 里的热数据挤掉，同一 Broker 上正常的实时消费者也跟着变慢、生产延迟上升。
所以追积压时要限速或错峰，并盯住 iostat 和 Broker 请求延迟。

五、Rebalance 风暴排查

现象：消费组频繁触发 rebalance，消费停滞

常见原因：
1. session.timeout.ms 太短（3.0 前默认 10s，3.0 起默认 45s），心跳被 GC/网络抖动卡住导致超时
   → 解决：结合 heartbeat.interval.ms（默认 3s，约为 session 的 1/3）调整，一般 30s-60s
2. max.poll.interval.ms 太短（默认5min），批量处理超时
   → 解决：调大或减少 max.poll.records
3. 消费者频繁上下线（发布/OOM/网络抖动）
   → 解决：优雅关闭 + 健康检查
4. 分区数变更触发 rebalance
   → 解决：尽量避免生产环境动态增加分区

协议优化：
- Kafka 2.4+：使用 CooperativeStickyAssignor 替代 RangeAssignor，增量 rebalance，只迁移需要移动的分区，不全部停消费
- Kafka 2.3+：静态成员（group.instance.id），实例重启时在 session.timeout 内回来不触发 rebalance
- Kafka 4.0+：新消费者组协议 KIP-848 GA（消费者设 group.protocol=consumer），Broker 端算分配、按成员增量调整，没有全组同步屏障

plaintext

六、Broker 抖动排查

现象	可能原因	排查
请求延迟飙升	磁盘 IO 满	`iostat -x 1`看 %util
ISR 频繁变化	网络抖动/replica.lag 配置	检查网络+调整 replica.lag.time.max.ms
Controller 切换	ZK 模式：ZK 会话超时；KRaft 模式：Controller Quorum 心跳/选举超时	ZK 模式查 ZK 状态+GC 日志；KRaft 查 Controller 节点 GC、网络和 `__cluster_metadata` 日志（4.0 起只有 KRaft）
日志段切割抖动	大 segment 切割时 fsync	调小 log.segment.bytes 降低单次 fsync 量

面试回答（2分钟版）

Kafka 运维我重点关注三类指标。Consumer Lag 是最核心的，通过 kafka-consumer-groups 命令看每个分区的消费延迟，lag 持续增长说明消费跟不上需要扩容或修复瓶颈。ISR 收缩说明有副本同步落后，可能是网络或磁盘问题。磁盘和网络 IO 接近上限说明需要扩 broker。积压紧急处理我有三板斧：第一增加消费者（不能超过分区数），第二如果旧消息不重要直接重置 offset 到最新，第三修复消费端瓶颈通常是 DB 慢查询或外部调用超时。追积压时还要注意冷数据读会打穿 PageCache、走磁盘读，拖慢同一 Broker 上的实时消费，所以要限速。消费端常见的坑是 Rebalance 风暴，通常是 session.timeout 太短导致心跳被 GC 或网络抖动卡住判超时，或者 max.poll.interval 太短导致两次 poll 之间的消费逻辑处理超时，解决方案是调大超时、减少 max.poll.records，或用 CooperativeStickyAssignor 做增量 rebalance，4.0 起还可以切到 KIP-848 新协议。

追问与易错

追问方向：

“消费者数大于分区数会怎样？”→ 多余的消费者空闲，不会分配到分区
“零拷贝具体省了什么？”→ 传统：磁盘→内核缓冲→用户缓冲→socket缓冲→网卡；sendfile：磁盘→内核缓冲→网卡，省掉两次用户态拷贝和两次上下文切换
“acks=all 和 ISR 的关系？”→ acks=all 要求 ISR 中所有副本确认（3.0 起生产者默认 acks=all 且默认开启幂等）；ISR 缩小到只剩 leader 时效果退化为 acks=1，所以要配 min.insync.replicas≥2，ISR 不足时写入直接报 NotEnoughReplicas 而不是悄悄降级
“怎么保证消费有序？”→ 单分区内有序；跨分区无序；业务有序就指定 partition key，让同 key 进同一分区

易错点：

❌ “扩消费者就能解决积压”——普通消费者组里消费者数超过分区数，多余的就空闲（4.2 起生产可用的共享组 Share Group / Queues for Kafka 可以多个消费者分摊同一分区，但不保序）
❌ “Kafka 高性能靠内存”——靠的是 OS Page Cache 而非 JVM 堆内存
❌ “rebalance 是好事”——频繁 rebalance 意味着消费停滞，是性能杀手
✅ 核心思路：积压先看 lag 趋势，再定位瓶颈（消费端/broker/网络）