前阵子业务告警群里又炸了——消费延迟从平时的几百毫秒一路飙到分钟级，P99 延迟曲线在监控面板上直接拉成一条陡坡。接手这套 Kafka 系统两年，类似的戏码每隔一阵就重演一次。与其每次都临时救火，不如把全链路参数优化这件事系统捋一遍。这篇是 Kafka 系列进阶的第二篇，核心只聊三件事：吞吐量怎么往上提，延迟怎么按得住，以及在两者互相拉扯时参数该怎么取舍。适合已经跑通过基础收发流程、想深挖性能的开发者，也适合被消费积压折腾过的运维同事参考。

1. 调优第一步：先定义指标，再开始拧参数

1.1 吞吐和延迟是一对天生的对手

很多人一上来就急着改参数，结果参数堆了一堆，业务还是抱怨延迟高。问题往往出在没想清楚：你到底要优化什么。

Kafka 的吞吐和延迟在绝大多数场景下是互相较劲的。想要吞吐高，核心手段是"攒批"——把多条消息攒成一个大批次发出去，网络包更少、磁盘顺序写更高效，但代价是消息在生产端多等了一段时间。想要延迟低，就得来一条发一条，减少等待，代价是网络往返次数暴增，吞吐自然上不去。

我用一个类比给团队讲过这事：攒批好比拼车，拼车要等乘客凑齐才发车，满载率高、单趟运的人多，但乘客可能多等几分钟；低延迟好比打专车，随叫随走，单人单趟，体验好但运力效率低。调优的本质，就是搞清你的业务到底适合拼车还是专车。

1.2 先把指标口径定清楚

动手之前，一定要把指标定义明白，否则后面全是糊涂账。

第一个指标是吞吐量。线上一般用两种口径：每秒处理的消息条数（msg/s）和每秒处理的字节数（MB/s）。消息体积差异很大时，只看条数是会骗人的——一个小消息场景每秒几十万条，大消息场景可能每秒不到一万条，但后者的带宽压力反而更大。

第二个指标是延迟。这里要区分"端到端延迟"和"单段耗时"：端到端是从 Producer 发送消息到 Consumer 真正拿到消息的完整时间，通常用 P99 甚至 P999 衡量，比平均值更能反映真实体验。平均值拉平了毛刺，P99 才能暴露出尾部的慢请求。

建议在优化前写下一行目标，比如"吞吐达到 8 万条/秒，端到端 P99 小于 50ms"。有了这个数字，后面每个参数的取舍都有依据，不会东一榔头西一棒子。

1.3 没有基线，调优就是在裸奔

这个坑我踩过不止一次。有一次接手某个日志采集系统，我直接调高了压缩和批量参数，吞吐从 4 万涨到 6 万，当时还挺得意。结果业务第二天找过来，说 P99 从 30ms 涨到了 130ms，他们完全不能接受，最后只能回滚。

那次之后我给自己立了规矩：调优前先压一轮测试，记录基线数据；之后每改一个参数，都拿新数据和基线对比。基线数据至少包括吞吐量、P99 延迟、Broker CPU、内存、磁盘 IO 这几项。没有基线，所谓的"优化"只是凭感觉，出了问题连是哪个参数拖累的都说不清楚。

2. Producer 端参数：在攒批与实时性之间精打细算

2.1 acks 是可靠性和吞吐的第一道杠杆

acks参数决定了 Producer 要等到多少副本确认后才认为发送成功，它对语义的影响远大于对吞吐的影响。

acks=0表示消息发出就算成功，不管 Broker 是否收到。这种配置吞吐最高，但丢消息概率也最高，除了极端的监控日志场景，生产环境我不建议用。acks=1表示 leader 副本写入成功就算成功，这是吞吐和可靠性的常见折中点。acks=all表示所有 ISR 副本都写入成功才算成功，配合min.insync.replicas才能保证 leader 挂了也不丢已确认消息。

很多人一看到acks=all就本能抗拒，觉得吞吐肯定垮。实际上只要分区数充足、ISR 里没有拖后腿的慢副本，acks=all的额外代价没有想象中那么大。真正让性能崩掉的，往往不是 acks 本身，而是某个副本同步跟不上，ISR 反复收缩，整个发送链路被卡住。所以别只盯着参数，副本健康状态更要时刻盯紧。

2.2 攒批三兄弟：linger.ms、batch.size、buffer.memory

这三个参数是 Producer 吞吐优化的重头戏，也最容易让人迷惑。

linger.ms默认是 0，也就是来一条发一条。对单条几百字节的小消息来说，这等于每发一条消息都要消耗一次完整的网络往返，吞吐非常难看。调到 5~20ms 后，Producer 会在这段时间内攒消息，尽量填满批次再发送。这里有个理解误区：linger.ms不是"每条消息都必须等这么久"，它只是最长等待时间，如果batch.size提前攒满，批次会立刻发出。所以延迟敏感的场景设 5~10ms，吞吐优先的场景设 20ms 甚至更高，都不会出现"每条消息都被卡住"的错觉。

batch.size默认 16KB，指的是单个批次的内存上限，不是"攒够多少条才发"。如果单条消息 1KB，16KB 大约能装 16 条，这个批次容量太平庸；如果单条消息 10KB，16KB 的批次可能一条消息就占满，攒批效果为零。经验做法：用"单条消息大小 × 期望的批次条数"来估算，比如每条 1KB、希望一个批次装 200 条，就设batch.size=256KB左右。

buffer.memory默认 32MB，是 Producer 缓冲区总量。当 Broker 处理不过来时，消息会堆积在内存里；一旦缓冲区满了，send()就会阻塞（最长等待max.block.ms，默认 60s）。调大这个值能扛突发流量，但积压消息也意味着延迟升高，这是躲不开的权衡。

2.3 压缩选型：用 CPU 换带宽和磁盘

当网络或磁盘成为瓶颈时，开启压缩往往是性价比最高的动作。compression.type默认是none，但这在真实高吞吐场景里很少是最优解。

三个常见选项：lz4压缩速度快、CPU 开销小，适合对吞吐敏感的在线链路；zstd压缩率最高，大约比lz4再省 20%~30% 空间，但 CPU 开销更大；gzip现在基本不推荐了，压得慢又耗 CPU。

压缩这件事是 Kafka 自动透明的：Broker 存的是压缩后的数据，Consumer 拿到的还是解压后的原始消息，使用方无感知。我实测过一组数据：在千兆网卡接近打满的集群里，单条 1KB 的 JSON 日志，开zstd之后吞吐量提升了差不多 1.5 倍。代价是消费端反序列化时多花一点 CPU，但只要消费逻辑不复杂，这个开销通常不是瓶颈。

2.4 一个可以直接参考的 Producer 配置清单

下面这份配置是我在延迟目标 P99 小于 80ms、又希望吞吐尽量高的场景下反复压测后留下的版本：

acks=all linger.ms=10 batch.size=65536 buffer.memory=67108864 compression.type=lz4 max.block.ms=5000 enable.idempotence=true

开启幂等后，Producer 会自动带上 sequence number，Broker 能识别重复消息并去重，代价几乎可以忽略。如果业务完全不能接受任何重复消息，这套配置能保证 exactly-once 语义的基础前提。注意，linger.ms=10配合batch.size=64KB不是说每条消息都会等满 10ms，而是批次满了就发，网络空闲时最多等 10ms 就发出，对在线业务的延迟压力完全可以接受。

3. Broker 端参数：分区数、副本机制与 IO 模型

3.1 分区数不是越大越好

分区数决定了 Kafka 的并行度上限——一个分区的消息只能被同一消费组里的一个消费者线程消费，所以分区越多，理论上消费并行度越高。但"越多越好"是新手最容易犯的错误之一。

分区多带来的代价很实在：每个分区都有独立的 leader/follower 日志段和索引文件，文件句柄占用随之增加；副本同步时，Follower 线程需要逐个分区拉取消息，分区太多会让同步效率下降；极端情况下，分区数过多还会拖慢 leader 选举和 ISR 收缩的速度。

经验做法是从吞吐倒推：先估算单分区的极限吞吐（通常单分区顺序写磁盘时可以跑到几十 MB/s），再用"目标峰值吞吐 / 单分区吞吐"算出分区数下限，最后留 1.5~2 倍余量。比如目标峰值 200MB/s，单分区按 50MB/s 算，至少需要 4 个分区，保守一点建 8 个分区。另外要记住，分区只建议增加不建议减少，因为减少分区会触发完整重平衡，风险不小。

3.2 副本机制：min.insync.replicas 和 unclean 选举

副本参数的核心是解决"leader 挂了如何保证不丢消息"。min.insync.replicas默认是 1，如果 Producer 端设了acks=all，我强烈建议把 Broker 端的min.insync.replicas设为 2。两者配合，消息只有在"leader + 至少 1 个 follower"都写入成功后才算确认，这样即使 leader 挂了，已确认的消息在另一个副本里仍然完整存在。

但这个配置不是免费的：当 ISR 里的存活副本数少于 2 时，Producer 发送会直接报NotEnoughReplicas异常，相当于用可用性换可靠性。所以是否要设成 2，要看业务能不能接受短时写入失败。通常 3 副本 + min.insync.replicas=2 是比较稳妥的组合。

unclean.leader.election.enable这个参数更要小心。它默认是 false，但偶尔有运维为了"尽量让分区有 leader"而改成 true。这是一条不能碰的红线：开启后，leader 挂了可能会选一个数据落后很多的副本顶上，直接造成大量已确认消息丢失。宁可短暂不可用，也坚决不要启用 unclean 选举。

3.3 IO 线程和网络线程怎么调

num.network.threads默认 3，负责处理网络连接与请求收发；num.io.threads默认 8，负责磁盘读写和实际的消息存储操作。这两个参数没有万能答案，得结合机器核数和实际压测来定。

在 16 核以上的机器上，我通常会把num.io.threads调到 12 到 16，网络线程调到 4 到 6。但要注意，IO 线程和网络线程不吃内存，它们吃的是 CPU。线程设太多，上下文切换开销会把收益抵消掉。最稳妥的办法是压测时用top观察 CPU 使用率：如果多个核心都跑到了 80% 以上，再加线程已经没有意义，瓶颈已经转移到磁盘或网络上。

3.4 页缓存：Kafka 高性能的真正幕后功臣

很多人以为 Kafka 的高吞吐全靠堆内缓存，其实恰恰相反。Kafka 在写入时先落到操作系统的页缓存（page cache），磁盘刷盘是异步的；读取时如果数据还在页缓存里，直接通过sendfile零拷贝发到 socket，CPU 几乎不参与数据复制。

理解了这一点，就明白为什么 Kafka 的 JVM 堆内存不需要设太大——堆主要用来存分区元数据、索引信息和一些内存池，通常 6~8GB 就够。把内存尽量留给操作系统做页缓存，才是正确姿势。我看到过有人把堆设到 20GB，结果 GC 频繁导致吞吐骤降，这是典型的"好心办坏事"。

3.5 文件段与索引参数

log.segment.bytes默认 1GB，控制日志段文件的大小。段越大，单文件能容纳的消息越多，但段内索引条目也越多；段太小会导致段文件数量爆炸，增加文件句柄和索引维护开销。一般保持默认即可，不需要刻意调整。如果消息体积特别小且数据量巨大，可以适当调大到 2GB；如果磁盘空间紧张，也可以调小些，但不建议低于 512MB。

4. Consumer 端参数：拉取窗口、消费线程与重平衡

4.1 fetch.min.bytes 与 fetch.max.wait.ms 的正确姿势

Consumer 是 pull 模式，主动去 Broker 拉数据。fetch.min.bytes控制"至少攒多少字节才返回一次"，fetch.max.wait.ms控制"最多等多久就返回一次"。这两个参数的关系，和 Producer 端的batch.size + linger.ms很像。

想压低延迟，就把fetch.max.wait.ms设小，比如 50~100ms，这样 Consumer 最多等这么短时间就有数据回来。想提高吞吐，就把fetch.min.bytes调大，比如 64KB 甚至更大，这样每次拉取都能带走一批数据，减少拉取次数。两种思路对应两类业务场景：在线接口关注延迟，离线批处理关注吞吐。注意，fetch.max.wait.ms默认 500ms，对小消息低延迟场景来说这个默认值有点偏高。

4.2 max.poll.records 和消费循环的工期控制

max.poll.records默认是 500，也就是一次poll()最多返回 500 条。这个参数的隐患在于：如果每条消息的业务处理耗时很长，一次 poll 返回 500 条可能要处理几十秒，一旦超过max.poll.interval.ms（默认 5 分钟），Consumer 会被判定为"死亡"并踢出消费组，触发全体重平衡。

我的建议是：先算一笔账，单条消息的平均处理耗时乘以max.poll.records，要保证一轮处理时间控制在几秒内。如果处理一条消息需要 20ms，500 条就是 10 秒，还勉强可以；如果单条处理需要 100ms，500 条就是 50 秒，这时候要么把max.poll.records降到 100，要么把处理逻辑异步化，把poll()拿到的消息交给专门的工作线程池去处理。

4.3 手动提交 offset：宁可重复，不要丢失

enable.auto.commit默认是 true，但生产环境我更建议改成 false，然后手动提交 offset。原因很简单：自动提交的时机不可控，很可能在消息处理完成后、下次自动提交前发生重平衡，导致这批消息被重复消费。

手动提交也有讲究。最稳妥的姿势是"先处理后提交"，保证消息真的处理成功了才更新 offset。这样重平衡时最多重复消费，但不会丢数据。对大部分业务来说，重复消费比丢数据更容易接受，配合消息幂等设计就能把这个副作用消掉。提交频率上，不需要每条都提交，可以在一个处理批次结束后统一提交一次，但务必确保在max.poll.interval.ms内完成。

在 Kafka 中，消费组需要在 session.timeout.ms 内发送心跳。默认值在不同版本略有差异，如果消费者处理耗时偏长，可以把 session.timeout.ms 适当调大，但要记得同时调整心跳频率和 max.poll.interval.ms，否则反而容易触发重平衡。

4.4 重平衡：高吞吐的隐形杀手

重平衡（rebalance）是最容易被忽略的性能杀手。重平衡期间，整个消费组的所有消费者都会暂停消费，直到分区重新分配完成。如果消费组很大、挂掉一个消费者导致全组 10 秒都不能消费，这损失比吞吐指标低几个百分点严重得多。

触发重平衡的常见原因包括：消费者加入或退出、订阅的 topic 新增分区、心跳超时被踢出。降低影响的办法有几个：一是使用静态消费者（static membership），让消费者重启后保持原有成员身份，避免触发重平衡；二是把heartbeat.interval.ms和session.timeout.ms合理配对，心跳更快一点、超时更长一点；三是最重要的——不要在 poll 循环里写重量级逻辑，比如同步访问数据库或调用远程接口，这种慢操作几乎一定会引发一连串重平衡。

5. 容易被忽略的 OS 层：页缓存、swap 与网络栈

5.1 swap 是 Kafka 性能的隐形杀手

虚拟内存 swap 一旦被频繁使用，Kafka 的延迟和吞吐都会断崖式下跌，因为页缓存被换到磁盘，读写直接打在慢速存储上。Linux 默认的vm.swappiness是 60，这个值对 Kafka 来说太高了。

标准建议是设成 1，甚至 0。设成 1 的意思是"除非万不得已，否则别用 swap"，这样既保留了 swap 作为内存溢出的最后防线，又不会让内核没事就把 page cache 换出去。改法很简单，写到/etc/sysctl.conf里永久生效。这个参数看着不起眼，但踩过 swap 坑的人都知道那是一种什么体验——明明磁盘和网络都还好，P99 就是莫名其妙飙到几秒。

5.2 文件句柄：分区一多就爆的隐藏坑

Kafka 每个分区、每个副本都会占用文件句柄，尤其是分区数动辄几百上千时，文件句柄很快会吃满系统默认限制。默认ulimit -n在不少机器上只有 1024，生产环境绝对不够。

建议把软限制和硬限制都调高，至少 65535 起步，分区特别多的集群可以设到 100 万以上。如果集群跑在容器或 Kubernetes 里，还要检查容器层面的 limit 配置，否则宿主机改了没用，容器里照样报Too many open files。这个坑很隐蔽，一旦分区数涨上去，Broker 可能莫名奇妙开始拒绝请求。

5.3 网络栈：网卡队列和 socket 缓冲

高吞吐场景下，网络软中断会成为新的瓶颈。表现是单个 CPU 核心的软中断占用率到 100%，但其他核心很闲。解决办法是开启网卡多队列（ethtool -l能看到队列数），并让irqbalance把不同队列的中断分散到多个 CPU 核心上。

socket 缓冲区大小也值得看一眼。net.core.rmem_max和net.core.wmem_max过小，在高带宽下会导致 TCP 吞吐受限。可以在/etc/sysctl.conf里调大这两个值，同时配合 Producer 端的socket.send.buffer.bytes和socket.receive.buffer.bytes一起调整。需要说明的是，这一步属于网络瓶颈场景的专项调优，不是每个集群都必须动。

5.4 磁盘挂载与 IO 调度

Kafka 强烈依赖磁盘顺序写性能，所以磁盘挂载参数直接决定写入稳定性。挂载 ext4 时建议加上nodelalloc和noatime，前者禁用延迟块分配，让日志数据更及时落盘，后者避免读文件时产生不必要的 atime 写 IO。后者避免了无谓的元数据写入，对小文件读多的场景尤其友好。

磁盘 IO 调度器方面，机械盘建议使用deadline调度器，SSD 建议使用none或noop，避免内核默认的cfq在大量顺序写场景造成调度延迟。

6. 压测方案：用同一把尺子验证调优效果

6.1 官方工具比自定义脚本更省心

Kafka 自带的生产者和消费者压测工具是最省心的选择，它们变量少、结果格式统一、基本能满足绝大多数基准测试需求。生产者压测命令大致长这样：

kafka-producer-perf-test.sh \ --topic perf-test \ --num-records 5000000 \ --record-size 1024 \ --throughput 100000 \ --producer-props bootstrap.servers=broker-1:9092 \ linger.ms=10 \ batch.size=65536 \ compression.type=lz4

消费者压测则是：

kafka-consumer-perf-test.sh \ --bootstrap-server broker-1:9092 \ --topic perf-test \ --messages 5000000 \ --timeout 600000

工具会输出吞吐量（msg/s 和 MB/s）以及延迟分位数。注意第一次压测前先确保 topic 里攒够数据，否则消费者工具跑不了真实数据量。

6.2 变量控制：一次只改一个参数

压测最大的敌人不是环境不稳定，而是同时改多个参数导致结论无法归因。我见过有人一次改了压缩、linger.ms、分区数三个变量，最后吞吐涨了却完全不知道是哪个参数起了作用。

正确做法是：先用默认配置跑一轮基线，然后每轮只改一个参数，记录结果。整个流程可以用一张简单的表来跟踪，参数、值、吞吐、P99、CPU、磁盘 IO 全都记下来。压测环境尽量贴近线上：机器规格相同、磁盘类型相同、网络拓扑相同，否则压测结果搬到线上可能完全对不上。

6.3 一组真实的调优前后对比参考

我拿一个小消息场景（每条 1KB JSON）举例，压测结果大致如下：

同样是这批消息，吞吐从 4.1 万涨到 7 万，P99 延迟也只从 35ms 涨到 52ms，对于日志采集类业务完全可以接受。但如果业务要求 P99 必须小于 40ms，那就得退回优化A，甚至把linger.ms降到 5ms 以下。

7. 一次延迟毛刺的完整排查链路：从监控告警到根因复现

7.1 现象与第一轮假设

某个业务系统每到晚高峰就报个别接口 P99 抖动，毛刺集中在每小时的 0 分、15 分、30 分、45 分附近，每次持续几十秒，然后自动恢复。虽然对绝大多数请求没有影响，但问题是 P99 诡异地从 30ms 跳到接近 2 秒，业务方不能接受。

刚开始我把怀疑对象锁定在 Broker 的 GC 停顿。Kafka 虽然堆内存不大，但 Full GC 一旦发生，所有请求处理线程都可能暂停，P99 毛刺非常符合这个症状。

7.2 排除 GC，转向磁盘 IO 证据

检查了 Broker 的 GC 日志和分析结果，结论是：Young GC 确实每分钟左右发生一次，但停顿只有 20~40ms，和 2 秒的毛刺完全不成比例；Full GC 几乎看不到，几分钟才一次，且耗时也在 100ms 以内。GC 这条假设被排除了。

转看iostat，发现了可疑点：磁盘 util 在毛刺出现的时刻会从 20% 左右跳到 80% 以上，同时await明显上升。但 Kafka 的日志读写是顺序追加，理论上不会出现这种周期性的大起伏。问题更可能出在"别的进程在抢占磁盘 IO"。

7.3 抓到真正的元凶：一个老监控脚本

用lsof查看哪些进程在访问 Kafka 数据目录，结果发现每隔 15 分钟就有一个监控采集脚本对 Kafka 日志目录做遍历统计。这个脚本是历史遗留的产物，作用是统计每个目录的文件数量和总大小，但它遍历时会触发大量元数据读和预读操作，把热数据从 page cache 里挤出去，导致 Kafka 后续读请求直接打到磁盘。

这正是那种只能在生产环境里碰到、文档里绝对翻不到的问题。参数层面没有一处是错的，但系统层面被一个不相干的进程拖垮了。

7.4 修复方案与验证

处理方式分两步：第一步，删掉那个定时扫描脚本的逻辑，改用已有的指标采集接口；第二步，把 Kafka 的数据目录挂载到独立的磁盘上，避免其他 IO 任务和 Kafka 日志读写互相干扰。上线后持续观察了一周，P99 毛刺彻底消失，晚高峰也能稳定保持在 50ms 以下。

这个案例给我的启发是：调优不能只盯 Kafka 参数本身。全链路的意思，是连监控采集、日志切割、系统定时任务这些"外部干扰"也要一起纳入视野。

8. 全链路参数速查与实际经验清单

我把多年实践里沉淀下来的常用参考配置整理成一个速查表，适合大多数通用生产场景。实际部署时请根据业务目标、机器规格、消息大小再做微调。

写到这里，再分享一点我自己的体会。调优这件事，最大的陷阱是总想找一个"银弹参数"，其实大多数场景下的收益排序都是：先看有无硬件和 OS 层干扰，再调拢批和压缩，再考虑副本和分区设计，最后才去抠那些边角参数。参数表只是一个起点，真正可靠的标准永远是压测数据。你在任何一个生产集群上做过的基线记录，都比网上流传的"最优配置"可信得多。

最后再分享一个小技巧：调优过程中，每改动一个参数，都在配置注释里写下改动的日期、原因和实测结果。这样三个月后回看，你能清楚地知道这套配置是怎么演化来的，也方便下次微调时快速定位方向。Kafka 的参数不会跑，跑的是你的集群，把这些细节管好，比临时抱佛脚改十个参数有用得多。