提升 Kafka 集群的整体吞吐量是一个系统性工程，不能仅仅局限于 Broker 端，而是需要从 Producer（生产者）、Broker（服务端）、Consumer（消费者） 以及 基础设施/架构设计 四个维度进行协同调优。

在调优前，我们需要明确一个核心的权衡原则：高吞吐量往往需要以牺牲一定的延迟（Latency）或部分可靠性（Reliability）为代价。

以下是提升 Kafka 吞吐量的核心参数调优指南：

---

一、 Producer 端调优（提升写入吞吐）

Producer 端的核心思路是：微批处理（Batching） 和 数据压缩（Compression），减少网络 I/O 次数。

1. batch.size (批次大小)
   • 调优： 默认 16KB，建议调大到 64KB、128KB 甚至 512KB。
   • 作用： Producer 会将发往同一个 Partition 的消息攒成一个批次发送。批次越大，网络请求次数越少，吞吐量越高。
2. linger.ms (延迟等待时间)
   • 调优： 默认是 0，建议设置为 10 - 100 毫秒。
   • 作用： 配合 batch.size 使用。如果数据产生较慢，凑不够 batch.size，Producer 会最多等待 linger.ms 时间后发送。人为增加微小延迟，可以大幅提升批处理效率。
3. compression.type (压缩算法)
   • 调优： 默认 none，建议设置为 lz4 或 zstd。
   • 作用： 在 Producer 端压缩数据，Broker 端直接落盘（保持压缩状态），Consumer 端再解压。极大地节省了网络带宽和磁盘 I/O。lz4 吞吐极高，zstd 压缩率极高且吞吐不错。
4. acks (确认机制)
   • 调优： 默认 all (高可靠)。如果对极少量数据丢失可以容忍，设置为 1（Leader 写入即返回）甚至 0（发出去就完事）。
   • 作用： 减少 Producer 等待 Broker 确认的时间，大幅提升发送速率。
5. buffer.memory (发送缓冲区)
   • 调优： 默认 32MB。如果单条消息大或 batch.size 调大了，建议调大到 64MB 或 128MB。
   • 作用： 防止生产者在网络慢时因为缓冲区满而阻塞（阻塞达到 max.block.ms 会报错）。
6. max.in.flight.requests.per.connection (飞行请求数)
   • 调优： 默认 5。在不要求严格顺序的前提下，可以适当调大。
   • 作用： 允许 Producer 在收到 ACK 前发送多个请求，提升管道利用率。（注意：开启幂等性 enable.idempotence=true 时，此值最大只能设为 5 以保证顺序）。

---

二、 Broker 端调优（提升处理与落盘吞吐）

Broker 端的核心思路是：充分利用磁盘顺序写、榨干 OS Page Cache、提升网络和 I/O 并发处理能力。

1. 利用 OS Page Cache (不要强制刷盘)
   • 调优： log.flush.interval.messages 和 log.flush.interval.ms 保持默认。
   • 作用： 千万不要在 Kafka 层面配置同步刷盘。让 Kafka 把数据写入操作系统的 Page Cache，由 OS 决定何时异步 Flush 到磁盘。这是 Kafka 极高吞吐的核心基石。
2. num.network.threads (网络线程数)
   • 调优： 默认 3。建议设置为 CPU核数 + 1 或更高。
   • 作用： 负责接收和发送网络请求。如果集群网络流量非常大，增加此值可以避免网络请求排队。
3. num.io.threads (I/O线程数)
   • 调优： 默认 8。建议设置为 磁盘数量的 2-3 倍 或等于 CPU 核数。
   • 作用： 负责实际的磁盘读写。如果 I/O 成为瓶颈（可通过 JMX 监控 IO 线程空闲率），需要调大。
4. num.replica.fetchers (副本同步线程数)
   • 调优： 默认 1。建议调大至 3 - 5。
   • 作用： 提升 Follower 从 Leader 拉取数据的并发度，防止高吞吐下副本同步延迟（Lag）过大导致 ISR 频繁抖动。
5. log.segment.bytes (日志段大小)
   • 调优： 默认 1GB。如果是超高吞吐，可以考虑设置为 2GB。
   • 作用： 减少 Broker 频繁滚动创建新日志文件带来的磁盘开销。

---

三、 Consumer 端调优（提升消费吞吐）

Consumer 端的核心思路是：单次拉取更多的数据，并在本地进行多线程/异步处理。

1. fetch.min.bytes (最小拉取字节数)
   • 调优： 默认 1。建议设置为 1MB 甚至更大。
   • 作用： 告诉 Broker：“如果没有攒够这么多数据，先别返回给我”。减少频繁的空轮询和网络请求开销。
2. fetch.max.wait.ms (最大等待时间)
   • 调优： 默认 500ms。配合 fetch.min.bytes 使用。如果数据没达到最小字节，最多等这么长时间就返回。
3. max.poll.records (单次 poll 最大条数)
   • 调优： 默认 500。建议调大到 2000 或 5000。
   • 作用： 单次拉取更多消息。前提是： 消费端处理逻辑极快，或者你把拿到的数据丢到本地线程池异步处理，否则容易导致 session.timeout.ms 超时触发 Rebalance。
4. 异步处理与手动提交
   • 策略： 关闭自动提交（enable.auto.commit=false）。Consumer 主线程只负责 poll 数据，将数据放入内部队列，由多个 Worker 线程并发处理数据，处理完成后再手动提交 Offset。

---

四、 架构与基础设施层面（决定吞吐量上限）

1. Partition (分区数) 的合理设置
   • 核心原则： 并发度由 Partition 决定。Topic 的 Partition 数量应该 >= Consumer Group 中的消费者数量。
   • 估算公式： 目标总吞吐量 / Min(单 Producer 吞吐，单 Consumer 吞吐)。
   • 注意： 分区不是越多越好，过多分区会导致 Broker 选举耗时、内存占用大。单集群分区总数建议控制在几万以内。
2. 磁盘配置 (最关键的硬件)
   • 强烈建议使用 JBOD (多块独立磁盘)，并通过 Broker 的 log.dirs 参数配置多个目录。Kafka 内部会对 Partition 进行负载均衡，这比 RAID 性能更好。
   • 采用 SSD 或高转速机械硬盘，确保顺序写带宽足够。
3. JVM 内存调整
   • 不要给 Kafka 分配超大 Heap！
   • Kafka 重度依赖操作系统的 Page Cache 提升吞吐（零拷贝技术 Zero-Copy）。通常给 JVM 分配 6GB - 10GB 堆内存即可（主要是为了抵御频繁的 GC），把剩下的物理内存全留给操作系统做 Page Cache。
4. 操作系统调优
   • vm.swappiness = 1：尽量避免使用 Swap 交换区。
   • 文件描述符上限：修改 ulimit -n 为 100000+。
   • 网络 Socket 缓冲区：适当调大 OS 级别的 TCP 发送/接收缓冲区大小（net.core.wmem_default, net.core.rmem_default）。

总结归纳（面试/汇报话术）

“要提升 Kafka 吞吐量，我会打出一套组合拳：
首先在 Producer 端 开启 LZ4/ZSTD 压缩，并大幅调大 batch.size 和 linger.ms 以提高微批处理效率；
其次在 Broker 端，坚决依赖 OS Page Cache 避免同步刷盘，同时根据 CPU 和磁盘数量合理增加 network 和 io 线程数，并调大副本拉取线程防止 Lag；
然后在 Consumer 端 调大 fetch.min.bytes 和 max.poll.records 批量拉取数据，配合本地多线程异步消费；
最后在 架构层面，合理增加 Topic 的 Partition 数以提升横向扩展性，并确保 JVM 堆内存不要配置过大，将服务器大部分内存留给 OS Page Cache 发挥零拷贝的威力。”