在 CentOS 上提升 Kafka 网络吞吐量的实操指南
一 操作系统与网络基础优化
- 提升文件描述符与连接承载能力：将进程可打开文件数提升到至少65535，并调大内核网络队列与连接 backlog，例如：
- ulimit -n 65535
- sysctl -w net.core.somaxconn=65535
- sysctl -w net.ipv4.tcp_max_syn_backlog=4096
- 启用 TCP_NODELAY 与合理的 keepalive，降低小包延迟、保持长连接：
- sysctl -w net.ipv4.tcp_no_delay=1
- sysctl -w net.ipv4.tcp_keepalive_time=600
- 增大套接字缓冲区和 TCP 窗口，提升高带宽长连接场景的吞吐：
- sysctl -w net.core.rmem_default=131072；net.core.wmem_default=131072
- sysctl -w net.core.rmem_max=2097152；net.core.wmem_max=2097152
- sysctl -w net.ipv4.tcp_rmem=“4096 87380 6291456”
- sysctl -w net.ipv4.tcp_wmem=“4096 65536 6291456”
- 存储与文件系统：优先使用SSD；文件系统建议XFS；挂载选项启用noatime减少元数据写放大。
- 内存与虚拟内存：降低 swap 倾向，避免影响 page cache 与网络/磁盘吞吐：
- sysctl -w vm.swappiness=1
- sysctl -w vm.dirty_background_ratio=5
- sysctl -w vm.dirty_ratio=60（更大值可提升聚合写，但可能带来长停顿，需结合业务与监控评估）
二 Broker 关键网络参数
- 并发与队列：
- num.network.threads：处理网络请求线程，建议设为CPU 核数+1
- num.io.threads：处理磁盘 I/O 线程，建议≥磁盘数，常见为CPU 核数的 2 倍（不超过 3 倍）
- queued.max.requests：网络请求队列上限，适当增大以平滑峰值（如500–2000）
- 套接字与复制通道缓冲：
- socket.send.buffer.bytes / socket.receive.buffer.bytes：建议提升到1–2 MB
- replica.socket.receive.buffer.bytes：副本同步接收缓冲，建议≥64 KB
- 副本拉取并发：
- num.replica.fetchers：提升副本同步吞吐，建议2–4（视 CPU/磁盘/网络而定）
- 请求与消息上限：
- socket.request.max.bytes：放宽单请求上限，避免大消息/大批次被拒（如100 MB级别，需与业务与客户端一致）
- 典型示例（需结合实例规格与压测微调）：
- num.network.threads=17（16 核 + 1）
- num.io.threads=32
- queued.max.requests=1000
- socket.send.buffer.bytes=2097152
- socket.receive.buffer.bytes=2097152
- replica.socket.receive.buffer.bytes=131072
- num.replica.fetchers=3
- socket.request.max.bytes=104857600
三 生产者与消费者的网络相关配置
- 生产者（提升发送效率与有效带宽利用率）
- compression.type=lz4/snappy（在 CPU 允许下优先 lz4）
- batch.size=1048576（1 MB，按消息大小与延迟目标微调）
- linger.ms=20–100（允许适度攒批，降低请求次数）
- acks=1（吞吐优先）或 all（可靠性优先，吞吐下降）
- buffer.memory=67108864（64 MB 起，视并发与批量而定）
- 消费者（提升拉取效率与单次处理量）
- fetch.min.bytes=1048576（1 MB）
- fetch.max.wait.ms=500–1000
- max.poll.records：按处理能力设置，避免 OOM 与处理超时
- 说明：增大批次与攒批会带来更高延迟，需在目标吞吐与端到端延迟间权衡
四 容量规划与拓扑优化
- 分区与并行度：分区数决定最大并发度，通常应≥消费者线程数；但避免过度分区（元数据与 ZooKeeper/Controller 压力上升）。
- 带宽评估：例如万兆网卡理论上限约1250 MB/s；若单 Broker 峰值写入/复制/读取合计接近或超过该值，需通过增加 Broker/分区/副本并发或升级链路来解除瓶颈。
- 拓扑与网络：减少跨机房/跨域跳数，优先同机房低延迟高带宽网络；副本跨机架/可用区分布以提升容灾与并行拉取效率。
五 监控验证与压测流程
- 监控与指标：
- 系统层：网络吞吐（sar -n DEV 1）、TCP 重传（netstat -s）、磁盘 I/O（iostat -x 1）
- Kafka 层：Broker/主题/分区的入站/出站字节速率、请求耗时、请求队列长度、副本落后（ISR 变化）、错误率
- 可视化：使用 Prometheus + Grafana 建立吞吐、延迟、错误、请求排队等面板，持续观测
- 压测与迭代：
- 使用 Kafka 自带工具（如 kafka-producer-perf-test.sh）进行基线压测，分别验证不同批次、压缩、acks、并发下的吞吐与 P95/P99 延迟
- 按“单变量变更”原则迭代参数，每次变更后进行回归压测与容量评估，避免多因素干扰结论
