Kafka 高吞吐场景下如何优化 batch.size 和 linger.ms 参数？

在高吞吐场景下，适当调大 batch.size 和 linger.ms 能减少网络请求次数，提升吞吐，但必须接受延迟增加。这并非简单的参数修改，而是需要结合业务延迟容忍度、消息大小及 Broker 限制的综合调优过程。

核心结论：这两个参数是 Producer 端 batching 策略的核心。调大它们可以让生产者积攒更多消息再发送，从而减少请求开销，但会牺牲实时性。

先定位：确认业务是否能容忍毫秒级的延迟增加，检查当前 Producer 的发送频率和 batch 填充率。
先做：优先调整 linger.ms 让 batch 有机会填满，再根据网络 MTU 和 Broker 限制调整 batch.size。
再验证：观察 Producer 端的 records-per-request-avg 和 batch-size-avg 指标变化，确保未引发 OOM。

核心机制与常见误区

Kafka Producer 发送消息时，不会来一条发一条，而是先放入一个批次（Batch）。

batch.size 限制了一个批次能容纳的最大字节数。默认是 16KB。如果消息很小，这个批次可能很久都填不满，导致网络请求频繁但 payload 很小，吞吐上不去。

linger.ms 限制了 Producer 愿意等待批次填满的时间。默认是 0ms，意味着批次一有数据就尝试发送。如果设为 20ms，Producer 会多等 20ms，希望期间有更多消息进来填满 batch.size。

技术误区修正：很多文档提示 batch.size 不能超过 Broker 端的 message.max.bytes，这是概念混淆。message.max.bytes 限制的是单条消息的大小，而 batch.size 是一批消息的总大小。批次总大小实际受限于 Broker 的 request.max.bytes 及网络 MTU。通常 batch.size 无需纠结 message.max.bytes，但需确保单条消息不超标，且批次总大小不要过大导致请求超时。

配置与计算案例

调整前请务必备份原有配置，并在非高峰时段灰度发布。以下是 Java Producer 的典型配置片段，供参考：

props.put("linger.ms", "20"); // 默认 0，适当增加等待时间
props.put("batch.size", "32768"); // 默认 16384 (16KB)，适当增加批次大小
props.put("buffer.memory", "33554432"); // 确保缓冲区足够大，避免阻塞

参数调优计算案例：

假设业务目标吞吐为 10MB/s，平均消息大小为 1KB。

默认配置：batch.size = 16KB。每个批次约容纳 16 条消息。每秒需发送 10MB / 16KB ≈ 640 个请求。
优化配置：batch.size = 128KB。每个批次约容纳 128 条消息。每秒需发送 10MB / 128KB ≈ 80 个请求。
收益：网络请求次数减少为原来的 1/8，显著降低 Broker 处理请求的 CPU 开销和网络握手开销。

注意：如果消息大小波动大，建议配合 compression.type=lz4 使用，更大的 batch 通常能获得更好的压缩率，但会消耗更多 CPU。

Kafka 高吞吐场景下如何优化 batch.size 和 linger.ms 参数？

监控验证命令实操

不要只看感觉，要看指标。Producer 客户端通常暴露了以下关键 Metric，可通过 JMX 或 Prometheus 监控。

1. JMX 查询示例

使用 jmxterm 或 JConsole 连接 Producer 进程，查询 MBean kafka.producer:type=producer-metrics：

# 查看平均批次大小
get kafka.producer:type=producer-metrics batch-size-avg

# 查看每个请求包含的平均记录数
get kafka.producer:type=producer-metrics records-per-request-avg

# 查看请求平均延迟
get kafka.producer:type=producer-metrics request-latency-avg

2. Prometheus 查询示例

如果接入了 Prometheus，可使用以下 PromQL 观察调优效果：

# 观察 batching 效率是否提升
avg(kafka_producer_metrics_records_per_request_avg{job="kafka-producer"})

# 观察网络发送字节率
sum(rate(kafka_producer_metrics_outgoing_byte_rate_total{job="kafka-producer"}[1m]))

验证标准：records-per-request-avg 上升说明 batching 效果变好；batch-size-avg 接近你设置的 batch.size 值说明配置生效；request-latency-avg 显著增加说明 linger.ms 带来了预期的等待延迟。

风险排查与内存保护

调优过程中需重点关注以下风险，避免引发生产事故：

内存溢出（OOM）：调大 batch.size 后，如果发送速度跟不上，内存中积压的未发送批次会增多。必须确认 buffer.memory 足够，且监控 Heap 使用率。若缓冲区满，Producer 会阻塞甚至抛出 BufferExhaustedException。
延迟敏感业务：如果业务要求毫秒级响应，增加 linger.ms 可能是致命的。不要为了吞吐牺牲 SLA。建议 linger.ms 不要超过 100ms，除非业务明确允许。
网络超时：批次变大可能导致单次请求处理时间变长，注意检查 request.timeout.ms 是否足够，避免误判为超时重试。
Broker 限制：虽然 batch.size 不直接受 message.max.bytes 限制，但整个 Request 的大小受 Broker 的 request.max.bytes 限制。如果 batch 过大导致 Request 超标，消息会被拒绝。

调整过程中请记录调整前的值。如果观察到延迟飙升或错误率增加，立即回滚配置。