Kafka 消费调优作战手册

下游消费峰值 = 生产 10×，跨云 50ms，从未压测。这份手册把「客户场景讲清 + Kafka 参数吃透 + 现场怎么做」压成可背记、可对答、可对比的一份。所有参数默认值来自 Kafka 4.0 官网自动生成配置表（curl 直抓、脚本解析、64/64 零缺失）+ apache/kafka 源码逐字核对 + AWS MSK 官方文档 + 东京真机 POC。

① 客户场景与消费方式（背景基线）

先把客户的部署形态、数据流、消费方式讲到能对答如流。这些是所有建议的前提。

部署与数据流拓扑

核心矛盾

现有 broker 参数清单（客户实际值）

② 「10×」的两种语义 —— 整场沟通的分水岭

同一句「下游消费是生产的 10 倍」，有两种完全不同的语义，对应两套完全相反的解法。不先分清，后面所有调优都可能调错方向。

③ 三大地雷（开场就该主动点出，显专业）

④ 跨云 50ms 的数学（BDP）—— 要能在白板上推

这是「升机型也救不了跨云消费慢」的第一性解释，也是明天最有冲击力的一段。

带宽时延积BDP（带宽时延积）= 带宽 × RTT
单 TCP 连接吞吐上限 = min(接收窗口, 发送缓冲) / RTT

Kafka consumer 的 receive.buffer.bytes 默认 = 65536 (64KiB)  ← 显式正数，不是 -1
  → 单连接上限 = 64KiB / 50ms = 1.31 MB/s
  → 200B 消息 ≈ 6,550 msg/s；1KB ≈ 1,280 msg/s；10KB ≈ 128 msg/s

第二个天花板：fetch 深度 = 1（但与用户处理并行）

consumer 对同一 broker 同一时刻只允许一个 in-flight fetch（AbstractFetch 硬规则）。但精确说法是：同一 broker 的 fetch 深度=1，但 fetch 与用户处理是并行的——poll() 在返回本批前就发出下一轮 fetch。所以别说「fetch 完全不能流水线」，要说「单连接吞吐 ≈ 单次响应大小 / max(RTT+broker时间, 单批处理时间)」。默认下 TCP 窗口（1.31MB/s）比单分区 fetch 限额（20.97MB/s）低 16 倍 → 必须先调 receive.buffer.bytes，再调 fetch 参数才有意义，顺序反了没效果。

跨云 EC2 sysctl（客户自己的机器，完全可控）

/etc/sysctl.d/99-kafka-client.conf# 前提：客户端 Kafka receive.buffer.bytes 保持 -1 才走自动调节
net.ipv4.tcp_rmem = 4096 131072 33554432   # max=32MiB，50ms 下支撑 ~5Gbps 单流
net.ipv4.tcp_wmem = 4096  65536 33554432
net.core.rmem_max = 33554432               # 兜底：防显式设值被静默截断
net.core.wmem_max = 33554432
net.ipv4.tcp_window_scaling = 1            # 必须为 1，否则窗口物理封顶 64KiB
net.ipv4.tcp_moderate_rcvbuf = 1           # 自动调节总开关，必须为 1
# 教科书级判据：iperf3 -P 1 慢 而 -P 8 快 ⇒ 100% 是接收窗口不足

⑤ 分区 = 消费并行度的硬上限

Kafka 的 group 协议：一个 topic-partition 在同一 consumer group 内，同一时刻只被分配给恰好一个 consumer 成员（因为 __consumer_offsets 里每个 (group,topic,partition) 只有一条 committed offset，两个成员并发消费会互相覆盖）。所以：

一个 group 内「有效工作的 consumer 实例数」 ≤ 该 group 订阅的分区总数

实例数 < 分区数 → 每实例背多个分区（正常）
实例数 = 分区数 → 1:1，最大并行度
实例数 > 分区数 → 多出的实例分到 0 个分区，纯空转（--members 里 #PARTITIONS: 0）

10× 峰值需要多少分区（现场演算）

所需分区数 N ≥ ceil( R_peak / t_single ) × 1.5    再向上取整到 broker 数(12)的倍数
  R_peak  = 该 group 峰值消费速率（msg/s 与 MB/s 都算，取更严）
  t_single = 单实例单分区实测能力（必须实测，见现场压测方案）
  1.5      = 安全系数（GC / rebalance / 慢分区 / 倾斜余量）

加分区的三个代价（客户「愿意加分区」前必须知道）

1. 老数据不重分布：加分区只影响新写入 → 「加了分区 lag 没降」是正常现象 → 加分区是预防措施，不是急救措施，必须在峰值到来前做完。
2. 破坏 key→partition 映射 最重要：默认 partitioner 是 toPositive(murmur2(key)) % numPartitions（不是 hashCode）。16→36 后同一 key 落点改变 → 新消息在新分区、旧消息在老分区未消费完 → 两分区间无顺序保证。对交易/撮合/账务这是正确性事故，不是性能问题。缓解：排空后扩 / 新 topic 双写 / 自定义 Partitioner（hash%12288 固定模数再映射）。
3. 触发一次 consumer group rebalance：默认 RangeAssignor 是 eager = stop-the-world。用 CooperativeStickyAssignor 可降到只影响迁移的分区。

⑥ 大消息约束链（客户 10MB 消息，全链必须一起放大）

官方约束链producer  max.request.size          ≥ 10MB   ← 不满足：produce 直接失败
broker    message.max.bytes          = 10MB   ← 客户已设
broker    replica.fetch.max.bytes    ≥ 10MB   ← 不满足：复制退化→ISR收缩→生产被拒
broker    replica.fetch.response.max.bytes ≥ 32MB  ← 客户值超默认 120B，走 fallback
consumer  max.partition.fetch.bytes  ≥ 10MB   ← 不满足：消费退化，lag 单调涨
consumer  fetch.max.bytes            ≥ max.partition.fetch.bytes

⑦ 可靠性黄金四角（交易类客户专题）

持久性不是一个参数，是一个四元乘积。任何一个因子是 0，整个乘积就是 0。

acks=all × min.insync.replicas=RF-1 × unclean.leader.election=false × 幂等
   客户: ❓未知           ✅ =2                    ❌ 当前 true              ❓未知

参数速查 · Broker 端

默认值全部来自 Kafka 4.0 官网自动生成配置表。dyn=可动态改无需重启（cluster-wide）；ro=read-only 必须滚动重启。

参数速查 · Consumer 端（本次头号战场，客户值全部未知，必须问）

参数速查 · Producer 端

⑧ 现场分诊决策树

⑨ 三种 rebalance 彻底分清（客户误解的核心）

客户「怕 rebalance 所以不加节点」，把三件不同的事混成了一件。分清之后扩容选项会一下子变多。

⑩ 动作清单（红黄绿灯）

⑪ 必须问客户的清单（拿不到就是盲调）

⑫ Observer/Learner 前瞻（加分项，不是主菜）

是什么：给 Kafka 加第三种副本状态——全量同步数据但永不进 ISR。四个性质全是 Kafka 规则的推论：不拖 HW / 不拦 acks / 不算 minISR / 不被选主。5 个 hook 点，ZK 模式 ~60 行 Scala，核心 gate canAddReplicaToIsr（KIP-497@2.7 引入，所以 2.7+ 才支持）。真机验证：2.7→4.3 共 20 build × S1-S8 全绿；observer 在最慢 AZ 时 acks=all 仍 2.04-2.35ms（零拖累）；晋升 ≤10s 零重启零数据搬迁。

FAQ · 现场问答弹药

官方数字备查（被追问时报得出来）

开场话术（三句话建立信任，顺序不能变）