📚 课程目录第4章生产者性能调优

4. 生产者性能调优

生产者性能调优的本质，是在吞吐量、延迟、持久性、顺序性这四个目标之间做取舍。Kafka 生产者暴露了五个关键参数，它们彼此耦合，单独调一个往往得不到预期效果。理解它们之间的联动关系，比记住某个"最佳值"重要得多。

五个参数各自控制什么

acks 决定生产者何时认为一条消息"写成功"。acks=0 发出即返回，吞吐最高但可能丢消息；acks=1 只等 leader 落盘，leader 故障时可能丢；acks=all（等价 -1）要求 ISR 中所有副本确认，持久性最强，但每条消息的等待时间最长。它直接决定了单条请求的往返延迟下限。

linger.ms 是发送线程在缓冲区里"等一等"的时间。默认 0 表示有数据立即发。把它设为 5～100ms，生产者会攒够一批再发，显著提升批量效率，代价是人为引入延迟。

batch.size 是每个分区批次的内存上限（默认 16KB）。批次越大，压缩比越高、网络请求越少，但内存占用和单批延迟上升。注意：linger.ms 决定"等多久"，batch.size 决定"最多攒多少"，两者共同决定实际批大小——谁先触发谁发送。

compression.type 支持 none、gzip、snappy、lz4、zstd。压缩在客户端完成，broker 原样存储，消费者解压。压缩比越高，网络和磁盘压力越小，但 CPU 开销越大。lz4 和 zstd 通常是吞吐场景的首选。

max.in.flight.requests.per.connection 是每个连接上未确认请求的最大数量（默认 5）。它决定生产者的并发流水线深度。值越大吞吐越高，但一旦发生重试，可能打乱消息顺序——除非配合 enable.idempotence=true。

参数之间的耦合关系

这五个参数不是独立的旋钮。最典型的耦合有三组：

linger.ms 与 batch.size 共同决定批大小。如果 linger.ms=0，批次几乎总是"来一条发一条"，batch.size 设多大都没用；反过来，如果 batch.size 很小，linger.ms 设再大，批次也会被大小上限提前触发。
compression.type 的收益依赖批大小。压缩算法对单条小消息几乎无效，只有批次足够大时，压缩比才能体现出来。所以"开压缩"必须和"攒批"一起做。
max.in.flight 与 acks、幂等性相互制约。acks=all 时，每个请求的确认时间变长，提高 in.flight 才能填满流水线；但 in.flight>1 时若发生重试，顺序可能被打乱，此时必须开启幂等性。

实战配置：三类典型场景

下面给出三组可直接参考的配置，分别对应高吞吐、低延迟、强持久性场景。这些是教学示例参数，实际值需要根据集群规模、网络带宽和压测结果调整。

# 场景一：高吞吐日志采集（可容忍秒级延迟）
acks=1
linger.ms=50
batch.size=262144        # 256KB
compression.type=lz4
max.in.flight.requests.per.connection=5
buffer.memory=67108864   # 64MB，防止缓冲区打满阻塞

# 场景二：低延迟实时风控（毫秒级响应）
acks=1
linger.ms=0
batch.size=16384         # 16KB，默认值
compression.type=none    # 压缩会引入 CPU 延迟
max.in.flight.requests.per.connection=5

# 场景三：强持久性金融交易（不丢、不乱序）
acks=all
linger.ms=10
batch.size=131072        # 128KB
compression.type=zstd
max.in.flight.requests.per.connection=5
enable.idempotence=true  # 自动保证顺序与去重
retries=2147483647
delivery.timeout.ms=120000

如何判断调优是否生效

调优不能只看配置，要看指标。生产者端重点观察三个 JMX 指标：record-send-rate（发送速率）、record-queue-time-avg（消息在缓冲区等待的平均时间）、batch-size-avg（实际平均批大小）。

判断逻辑很直接：如果 batch-size-avg 远小于 batch.size，说明批次没攒满，可以适当提高 linger.ms；如果 record-queue-time-avg 已经接近甚至超过 linger.ms，说明延迟主要来自攒批，再增大 linger 会伤害实时性；如果 record-send-rate 上不去而 buffer.memory 使用率很高，说明下游 broker 或网络是瓶颈，继续调生产者参数收益有限。

调优顺序建议：先确定 acks 和幂等性（这决定持久性与顺序性底线），再调 linger.ms 和 batch.size（决定吞吐与延迟），最后选 compression.type（在吞吐和 CPU 之间找平衡）。max.in.flight 通常保持默认 5，除非压测证明网络往返是瓶颈。

不要盲目把 batch.size 设成几 MB。批次过大会导致内存压力、单批发送时间过长，且一旦失败重试代价很高。同时注意 buffer.memory 要能容纳所有分区的在途批次，否则 send() 会阻塞或抛异常。

一个容易忽略的细节：重试与顺序

当 max.in.flight.requests.per.connection > 1 且 retries > 0 时，如果第一批失败重试、第二批成功，消息顺序就会颠倒。Kafka 从 0.11 起提供幂等生产者解决这个问题：开启 enable.idempotence=true 后，broker 通过序列号去重，生产者会保证同一分区内消息按发送顺序写入。此时即使 in.flight=5，顺序性依然成立。这也是为什么在强持久性场景中，幂等性几乎是必选项。

总结成一句话：acks 定底线，linger 和 batch 定吞吐与延迟，压缩定资源开销，in.flight 定并发深度，幂等性定顺序保障。五者协同，才能得到既快又稳的生产者。