Kafka 生产者幂等为什么把 max.in.flight 锁死在 5：acks、顺序与吞吐的三角权衡

一、现象：开了幂等，吞吐没涨，顺序却「看起来」更乱了

先给结论：enable.idempotence=true 不是「加个开关就完事」，它会悄悄把 max.in.flight.requests.per.connection 从你写的值钳制到 5，并且只保证单分区内的不重不丢与顺序，跨分区、端到端它一概不管。 我见过两种典型翻车：

• 一个风控特征写入服务，Kafka 3.5（3 broker，min.insync.replicas=2，ISR=3），topic 16 分区、16 实例生产者，日均 6800 万条。把 enable.idempotence 从 false 改 true 后，单分区 P99 从 3.1ms 涨到 4.8ms，团队以为是「幂等拖慢了」，实际上慢在 acks 与 min.insync.replicas 的组合，跟幂等本身关系不大。
• 更隐蔽的一条：某订单事件链路开幂等后，偶发出现「同一订单的 create→pay 两条消息在同一个分区里倒序」。排查发现是多线程共用一个 Producer 实例，send 本身线程安全，但业务把「先 create 后 pay」当成顺序前提，而这两条是不同 key、落到了不同分区——幂等根本没承诺跨分区顺序。

二、原理：为什么是 5，而不是 1

要理解这三者，先拆开：

1. acks=all（即 -1）：leader 必须等所有 ISR 副本落盘才 ACK。它保证的是「不丢」，但不等于安全——真正决定下限的是 broker 端 min.insync.replicas。若 min.insync.replicas=1，ISR 缩到只剩 leader 时照样写成功，此时 acks=all 形同 acks=1。
2. max.in.flight.requests.per.connection：单条连接上允许同时未确认的请求数。它直接决定吞吐：越大，pipeline 越深，单连接能压出的带宽越高，但一旦发生重试，未确认的多个 batch 可能被打乱顺序。
3. enable.idempotence=true：broker 端为每个 (ProducerId, 分区) 维护一个 SequenceNumber，重复的 seq 直接丢弃。于是「重排」不再是问题——broker 能识别并拒绝乱序/重复的请求。

关键机制：正因为 broker 端有了幂等序号，客户端才敢把 in-flight 从「安全值 1」放宽到 5。Kafka 客户端在开启幂等时，会硬性把 max.in.flight.requests.per.connection 钳制到 5（你写 100 也没用，日志里会打印被覆盖）。5 是 broker 端幂等窗口能容忍的最大乱序深度，再大就可能超出序号校验范围，顺序保证失效。

所以三角关系是：

• 不开幂等：要保单分区顺序，必须 max.in.flight=1 + retries=0（或极小），否则重试即乱序——吞吐上不去。
• 开幂等：可以 max.in.flight=5 + retries=MAX，既保单分区顺序又能高吞吐。
• acks 与 min.insync.replicas 决定「不丢」，与顺序是两个正交维度，别混在一起调。

三、具体做法（可复现）

生产者配置（Kafka 3.5，Java client）：

# 关键四件套：顺序 + 不丢 + 高吞吐，缺一不可
acks=all
min.insync.replicas=2          # 写在 broker 端，ISR 至少 2 才允许写
enable.idempotence=true
max.in.flight.requests.per.connection=5   # 会被钳制到 5，写大也无效
retries=2147483647             # 幂等下可放心重试
delivery.timeout.ms=120000
batch.size=16384
linger.ms=5

验证「max.in.flight 被钳制」：把 max.in.flight.requests.per.connection=100，启动日志会看到 max.in.flight.requests.per.connection=100 is overridden to 5 because idempotence is enabled。

验证顺序与不丢（单分区 1000 万条）：

# 生产：单 key 保证落单分区，seq 自增
kafka-producer-perf-test.sh --topic seq-test --num-records 10000000 \
  --record-size 128 --producer-props \
  bootstrap.servers=broker1:9092,broker2:9092,broker3:9092 \
  acks=all enable.idempotence=true --compression-type lz4

# 消费校验：读回后按 seq 断言严格递增
kafka-console-consumer.sh --topic seq-test --from-beginning \
  --max-messages 10000000 --bootstrap-server broker1:9092 | seq_check.py

我实测一组数据（3 broker、min.insync.replicas=2、lz4、单分区）：

• max.in.flight=1, retries=0：单连接 ~41 MB/s，P99 6.2ms
• max.in.flight=5, retries=MAX, 幂等开：单连接 ~68 MB/s，P99 4.8ms，1000 万条 0 乱序、0 重复

四、踩过的坑 / 反直觉

1. acks=all 被当成「绝不丢」：实际丢没丢看 min.insync.replicas。我们 min.insync.replicas=1 时，一次磁盘故障 ISR 缩到 1，acks=all 依旧写入成功但副本没跟上——这是「不丢」的假象。
2. 幂等 ≠ exactly-once 端到端：幂等只覆盖「单生产者 → 单分区」这一段。要端到端不重，还得 transactional.id + 消费者 isolation.level=read_committed，否则消费侧仍可能读到未提交/重复数据。
3. 多线程共 Producer 不报错，但顺序前提被破坏：send 线程安全，但「A 先于 B」只有在同一分区且同一发送线程顺序调用时才成立。跨 key、跨分区，顺序天然不保证。
4. retries 不幂等时是危险项：不开幂等却把 retries 拉满，broker 超时重试就会造成「重复 + 乱序」，比不重试更糟。

五、结论与可复用清单

• 顺序与不丢是两个正交维度：顺序由 idempotence + max.in.flight≤5 + 单分区 保证；不丢由 acks=all + min.insync.replicas≥2 保证。别混调。
• 开幂等后 max.in.flight 会被钳到 5，写大无效；这也是吞吐能上去、顺序还不丢的原因。
• 上线前 checklist：
  1. broker 端 min.insync.replicas 是否 ≥2；
  2. 生产者 enable.idempotence=true + retries=MAX + acks=all；
  3. 需要端到端不重时，补 transactional.id + 消费侧 read_committed；
  4. 别把跨分区当成顺序链路，必要时用单分区或业务层补偿；
  5. 用「单 key 自增 seq + 消费断言递增」做回归，而非只看吞吐。

留一个开放问题：当一条业务链路的「顺序」其实是跨多个分区、多个服务的组合语义时，幂等 + 事务到底能兜到第几层？剩下那部分，是应该交给业务层 outbox，还是干脆承认「最终顺序靠对账」？想听听大家在 4.x 事务里的真实取舍。