4. Kafka 深度调优：生产者批量发送、压缩算法选择、消费者拉取模型、页缓存优化
Kafka 调优这件事，说实话，很多人一开始都搞错了方向。我见过不少团队，一上来就调 Broker 参数，结果 Producer 端和 Consumer 端根本没动，瓶颈照样卡在那里。今天咱们就聊聊四个最核心的优化点——生产者怎么发、压缩怎么选、消费者怎么拉、页缓存怎么用。这些都是我在线上环境里反复踩过坑才总结出来的。
核心观点：Kafka 的高吞吐，本质上是「批量 + 顺序 + 零拷贝」的组合拳。任何一个环节没打通，吞吐量都上不去。
4.1 生产者批量发送：别让消息「零碎」着走
Kafka 生产者的核心机制是批量发送。什么意思呢？就是消息不是一条一条发出去的，而是攒一批，一次性发。你想想看，如果每条消息都单独走一次网络请求，光 TCP 握手和协议开销就能把吞吐打下来 80%。
我个人习惯，刚接手一个系统时，第一件事就是看生产者的 batch.size 和 linger.ms 这两个参数。
| 参数 | 默认值 | 优化建议 | 说明 |
|---|---|---|---|
batch.size |
16 KB | 32 KB ~ 128 KB | 单批次最大字节数，不是攒满才发，而是尽量填满 |
linger.ms |
0 | 5 ms ~ 20 ms | 等待时间，给批次「攒人」的机会 |
buffer.memory |
32 MB | 64 MB ~ 256 MB | 生产者内存缓冲区，防止背压阻塞 |
compression.type |
none | lz4 / snappy / zstd | 压缩算法，减少网络传输量 |
这里有个常见的误区：linger.ms 不是延迟，而是「容忍延迟」。我见过有人把 linger.ms 设成 100ms，结果吞吐上去了，但端到端延迟也飙到了 100ms+。其实对于大多数日志采集场景，5~10ms 的等待就足够了。
我的经验：如果消息体本身就很小（比如几十字节），建议把 batch.size 调到 64 KB 以上，配合 linger.ms=5，吞吐能翻 3~5 倍。我在一个 IoT 项目里就这么干的，单机写入从 2 万条/秒直接干到了 12 万条/秒。
4.2 压缩算法选择：别小看那几 KB 的 CPU 开销
压缩这件事，说白了就是用 CPU 换带宽。Kafka 支持四种压缩算法：gzip、snappy、lz4、zstd。选哪个？我直接给结论：
- 追求吞吐：lz4 或 snappy。压缩比一般，但 CPU 开销极低。
- 追求压缩比：zstd。压缩比最高，但 CPU 消耗也最大。
- 别用 gzip：除非你带宽极度紧张，否则 gzip 压缩慢、解压也慢，不划算。
我曾经在一个日志平台项目里做过对比测试，数据量 1TB，结果如下：
| 算法 | 压缩比 | 压缩速度 (MB/s) | 解压速度 (MB/s) | 推荐场景 |
|---|---|---|---|---|
| lz4 | 2.1x | ~500 | ~800 | 高吞吐、低延迟 |
| snappy | 2.0x | ~400 | ~700 | 通用场景 |
| zstd (level 3) | 2.8x | ~200 | ~500 | 带宽敏感、存储成本高 |
| gzip | 2.5x | ~80 | ~150 | 不推荐 |
注意：压缩是在 Producer 端进行的，但 Consumer 端解压也会消耗 CPU。如果 Consumer 端 CPU 已经吃紧，别选 zstd，选 lz4 更稳妥。
4.3 消费者拉取模型：别让消费者「饿着」或「撑着」
消费者的拉取模型，说白了就是「拉多少、拉多快、怎么拉」。很多人以为消费者就是调个 poll() 就完事了，其实里面的门道不少。
先看几个关键参数：
fetch.min.bytes：每次拉取的最小字节数。默认 1 字节，建议调到 1 KB ~ 10 KB，避免频繁空拉。fetch.max.wait.ms：最大等待时间。默认 500ms，如果数据量不大，可以适当调低。max.poll.records：单次拉取的最大记录数。默认 500，如果每条消息很小，可以调到 1000~2000。max.partition.fetch.bytes：每个分区单次拉取的最大字节数。默认 1 MB，建议保持或适当调大。
我遇到过一个问题：消费者拉取速度跟不上生产者写入速度，导致消费延迟越来越大。后来发现是 fetch.min.bytes 设得太小，消费者一直在做「空拉」——每次拉回来几 KB 数据，但网络往返开销却一点没少。
我的建议：把 fetch.min.bytes 设成 5 KB，fetch.max.wait.ms 设成 100ms。这样既能保证批次够大，又不会让消费者等太久。我在一个实时风控系统里就是这么调的，消费延迟从 3 秒降到了 200ms 以内。
4.4 页缓存优化：Kafka 的「隐形加速器」
页缓存（Page Cache）是 Kafka 高性能的核心秘密之一。Kafka 为什么快？因为它几乎不自己做缓存，而是直接依赖操作系统的页缓存。
你想想看，当 Producer 写入数据时，数据先写到页缓存，然后由操作系统异步刷盘。当 Consumer 读取数据时，如果数据还在页缓存里，就直接从内存读，根本不用走磁盘。这就是所谓的「零拷贝」——数据从页缓存直接送到网卡，中间不经过应用层。
但页缓存也不是万能的。有几个坑要注意：
- 页缓存被「污染」：如果 Broker 上跑着其他 IO 密集型的进程，页缓存会被频繁换出，导致 Kafka 读写性能骤降。
- 内存分配不合理：页缓存占用的内存是动态的，但如果系统总内存太小，页缓存会被压缩，导致频繁缺页中断。
- 刷盘策略：
flush.messages和flush.ms控制刷盘频率。刷得太频繁，页缓存优势就没了；刷得太慢，宕机丢数据的风险就大了。
避坑指南：我曾经在一个 32 GB 内存的 Broker 上，把 vm.dirty_ratio 从默认的 20% 调到了 40%，结果页缓存写得太快，刷盘跟不上，导致 IO 抖动。后来我改成了 30%，配合 vm.dirty_background_ratio=10%，才稳定下来。记住：页缓存不是越大越好，要跟磁盘 IO 能力匹配。
4.5 整体优化流程图
下面这张图，是我自己总结的 Kafka 吞吐优化全链路。你可以把它当成一个检查清单：
4.6 总结一下
Kafka 深度调优，说白了就是四个字：批量、压缩、缓存、零拷贝。生产者端把消息攒成批次再发，选对压缩算法省带宽；消费者端控制拉取粒度，别做无谓的空拉；Broker 端用好页缓存，让操作系统帮你加速。
嗯，这里要注意：调优不是一锤子买卖。我每次上线新系统，都会先跑一周的压测，然后根据监控数据微调参数。没有银弹，只有持续迭代。