Henry's xyz

外观

Kafka 高性能原理 ​

Kafka 的高吞吐不是单点技巧，而是一组设计叠加出来的结果：顺序写、批量处理、Page Cache、零拷贝、分区并行、压缩和 Pull 模型。

总体链路 ​

Producer
  │  批量、压缩、异步发送
  ▼
Broker
  │  顺序追加、Page Cache、零拷贝
  ▼
Consumer
     批量拉取、按 Partition 并行处理

性能优化要顺着这条链路看：Producer 是否攒得起批次，Broker 是否顺序写和顺序读，Consumer 是否及时拉取并处理。

顺序写 ​

磁盘慢通常慢在随机寻址，而不是顺序吞吐。Kafka 把 Partition 设计成追加日志：

00000000000000000000.log
┌────────┬────────┬────────┬────────┐
│ msg 0  │ msg 1  │ msg 2  │ msg 3  │  append only
└────────┴────────┴────────┴────────┘

顺序写带来的好处：

  • 减少磁盘寻道
  • 写入模式简单，不需要频繁原地更新
  • Segment 只读后便于缓存、复制和删除
  • 和 Producer 批量发送天然匹配

Kafka 把“更新消息状态”的复杂度转移到 Offset 和 Consumer Group 元数据中，而不是修改原始消息。

批量处理 ​

Kafka 的性能单位通常不是单条消息，而是 Record Batch。

ProducerRecord
ProducerRecord      ──► RecordAccumulator ──► Record Batch ──► Broker
ProducerRecord

批量带来的收益：

位置收益
Producer减少网络请求次数
Broker减少系统调用和索引更新次数
网络提高包利用率
压缩批量越大，压缩率通常越好
Consumer单次 Fetch 返回更多数据，减少往返

关键配置：

配置作用取舍
batch.size单个 Partition 批次大小大批次提升吞吐，但占用更多内存
linger.ms等待更多消息组成批次增大可提升吞吐，但增加延迟
buffer.memoryProducer 总缓冲区太小会导致发送阻塞
max.request.size单个请求最大大小需要和 Broker 限制配套

Page Cache ​

Kafka 不把大量消息放在 JVM 堆里，而是依赖操作系统 Page Cache。

Broker JVM
  │  write()
  ▼
OS Page Cache
  │  异步刷盘
  ▼
Disk

这种设计减少了两类成本：

  • JVM 堆对象少，GC 压力低
  • 热数据直接从 Page Cache 读，不必进入应用层缓存

Consumer 追得比较近时，刚写入的数据通常还在 Page Cache 中，读取接近内存速度。这也是 Kafka 适合“实时日志流”的原因之一。

零拷贝 ​

普通文件发送到网络可能经历多次数据拷贝：

Disk -> Kernel Buffer -> User Buffer -> Socket Buffer -> NIC

Kafka 可以使用 sendfile 这类零拷贝机制，把文件数据从 Page Cache 直接发送到 Socket：

Disk/Page Cache -> Socket Buffer -> NIC

减少用户态和内核态之间的数据拷贝后，Broker CPU 消耗下降，网络吞吐更容易打满。

分区并行 ​

Partition 是 Kafka 的并行度单位。

Topic orders
├── Partition 0 ── Leader Broker 1 ── Consumer A
├── Partition 1 ── Leader Broker 2 ── Consumer B
└── Partition 2 ── Leader Broker 3 ── Consumer C

分区带来的能力：

  • 多 Broker 分摊写入和读取压力
  • Consumer Group 内多个 Consumer 并行消费
  • 不同 Partition 的 Leader 可分散在不同 Broker
  • 单个 Topic 可通过增加 Partition 扩展吞吐

但 Partition 不是越多越好。Partition 过多会增加：

  • Broker 文件句柄和内存占用
  • Controller 元数据管理压力
  • Rebalance 时间
  • Leader 选举和副本同步成本

压缩 ​

Kafka 支持 Producer 端压缩，Broker 通常直接保存压缩后的 Record Batch。

算法特点适用
lz4压缩/解压快，延迟低通用高吞吐场景
zstd压缩率高，CPU 成本较高网络或磁盘成本敏感
snappy速度快，压缩率中等兼容性场景
gzip压缩率较高，CPU 成本高低频、大批量

压缩的收益不只是节省磁盘，也能减少网络传输和 Page Cache 占用。代价是 Producer 和 Consumer 需要更多 CPU。

Pull 模型 ​

Kafka Consumer 主动拉取消息，而不是 Broker 主动推送。

Pull 模型的好处：

  • Consumer 可以按自身处理能力控制速率
  • Broker 不需要维护复杂的每客户端推送状态
  • Consumer 可以批量拉取，提升吞吐
  • 消费失败后可按 Offset 重放

关键配置：

配置说明
fetch.min.bytesBroker 至少积累多少字节再返回
fetch.max.wait.ms最长等待时间
max.partition.fetch.bytes单个 Partition 单次 Fetch 最大数据量
max.poll.records单次 poll 返回的最大记录数

性能调优方向 ​

高吞吐 Producer ​

properties
compression.type=lz4
batch.size=131072
linger.ms=10
buffer.memory=67108864
acks=all
enable.idempotence=true

低延迟 Producer ​

properties
linger.ms=0
batch.size=16384
compression.type=lz4
acks=1

低延迟配置要谨慎牺牲可靠性。如果业务不能丢消息，acks=all 和副本配置优先级高于延迟。

高吞吐 Consumer ​

properties
fetch.min.bytes=1048576
fetch.max.wait.ms=500
max.poll.records=1000

如果处理逻辑慢，应优先优化业务处理或扩容 Partition / Consumer，而不是盲目增大拉取批次。

判断瓶颈 ​

现象可能瓶颈
Producer bufferpool-wait-time 高Broker 写入慢或网络慢
Request 延迟高Broker 磁盘、网络、ISR 同步慢
Consumer Lag 持续增长Consumer 处理慢或 Partition 并行度不足
Broker CPU 高压缩、解压、网络线程不足
磁盘 Util 高写入量过大、保留策略不合理、刷盘过频

参考 ​