Kafka是大型架构必备技能,下面我就重点详解Kafka生产者如何实现高吞吐@mikechen
批量发送优化
Kafka 的 Producer 并不是每写一条消息就立即发送,而是将多条消息收集起来。
组成一个批次(batch)一起发送,以减少网络开销并提高吞吐。
这里适当增加 linger.ms
的值(例如:设置为几毫秒…..到几十毫秒)。
[ Producer Record ] ↓ [ Buffer Pool ] ← 多条消息缓冲 ↓ [ Batch formed ] ← 达到 batch.size 或 linger.ms 触发发送 ↓ [ Kafka Broker ]
允许生产者收集更多消息形成更大的批次,从而提高吞吐量。
但需要注意,过高的 linger.ms
会增加消息的端到端延迟。
异步发送机制
Kafka Producer 的 send()
方法是异步的,调用后会立即返回一个 Future<RecordMetadata>
对象。
producer.send(record, (metadata, exception) -> { if (exception == null) { System.out.println("Success: " + metadata.offset()); } else { exception.printStackTrace(); } });
生产者发送消息后不立即等待 Broker 的响应,而是继续发送后续消息,通过回调机制处理发送结果。
这样,生产者无需等待 Broker 的确认,可以流水线式地发送消息,极大地提高了发送速率。
压缩机制
在生产者端对消息数据进行压缩,减小网络传输的数据量,从而提高有效吞吐量。
比如:
gzip
: 压缩率高,但 CPU 消耗也相对较高。
snappy
: 压缩和解压缩速度快,CPU 消耗较低,压缩率适中。
在吞吐量和 CPU 利用率之间提供了较好的平衡,是常见的选择。
lz4
: 压缩和解压缩速度非常快,CPU 消耗很低,但压缩率可能不如 gzip
或 snappy,
适用于对延迟非常敏感的场景。
zstd
: 提供比 gzip
更高的压缩率,同时保持良好的压缩和解压缩速度,但 CPU 消耗可能略高。
在高吞吐场景中推荐使用 lz4
、或 zstd
。
在对 CPU 敏感的系统中可选择 snappy
。
并发发送能力
Kafka Broker 利用 Page Cache 顺序写,提高写入效率。
当 Kafka Broker 接收到生产者的消息并需要将其写入磁盘时,它首先将数据写入到操作系统为该日志文件维护的 Page Cache 中。
由于是顺序写入,新的数据总是追加到 Page Cache 的尾部,这是一个非常快速的内存操作。
顺序写极大地减少了磁盘寻道时间,而 Page Cache 的使用将大部分写操作变成了快速的内存操作,只有在操作系统进行刷盘时才会有磁盘 I/O。
这种机制,使得 Kafka Broker 能够承受非常高的写入吞吐量。
mikechen睿哥
mikechen睿哥,10年+大厂架构经验,资深技术专家,就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注「mikechen」公众号,获取更多技术干货!

后台回复【架构】即可获取《阿里架构师进阶专题全部合集》,后台回复【面试】即可获取《史上最全阿里Java面试题总结》