摘要本文系统梳理提升 Kafka 吞吐与稳定性的十项关键调优，并结合生产经验给出参数示例、取舍建议与监控要点。内容涵盖主题分区、复制滞后、代理线程、生产者压缩、确认策略、消费者抓取、网络缓冲、KRaft 元数据超时、磁盘日志目录与复制因子。读完你可建立一套具备技术深度与工程可执行性的 Kafka 调优方法论。
架构总览（图解）Producer → RecordAccumulator/Batch → Socket Send → NIC TX → Network
↓
Broker Socket Receive → Broker Threads → Page Cache → Log Segments (log.dirs)
↓
Consumer Fetch → Socket Receive → Application
关键瓶颈通常出现在：分区并行度不足、复制滞后、网络/磁盘 IO 饱和、抓取批次过小或等待过长。
1) 增加分区数量（提高并行度）原理：分区是并行与扩展的基本单位，消费者组的并发度≈分区数。实践：热点主题优先扩分区，但避免超过消费者实例数太多导致上下文切换增多。命令示例：# 增加主题分区数（注意不可减少）
kafka-topics.sh --bootstrap-server
--alter --topic orders --partitions 64
经验：批次大、压缩好时分区更易发挥并行优势；观察 record-send-rate 与端到端延迟平衡扩分区节奏。2) 控制复制滞后 replica.lag.time.max.ms原理：跟随者滞后超过阈值会被踢出 ISR，影响持久性与写入确认路径。配置：# broker/server.properties
replica.lag.time.max.ms=5000 # 示例：5s，需结合网络/磁盘能力与延迟容忍度
取舍：滞后阈值太短易频繁出入 ISR，太长则风险积累；结合 min.insync.replicas 与 acks 联动。3) 调整代理线程 num.network.threads / num.io.threads原理：网络线程负责连接与请求，IO 线程处理磁盘与日志操作。配置：# broker/server.properties
num.network.threads=8
num.io.threads=16
num.replica.fetchers=4
经验：磁盘为 SSD 且网络连接多时适当加大 IO/网络线程；监控线程池队列长度与请求处理时间。4) 生产者压缩 compression.type原理：减小网络传输与磁盘写入体积，提高吞吐；常用 lz4 兼顾速度与压缩率。// Producer 配置示例（Java）
Properties props = new Properties();
props.put("bootstrap.servers", "broker1:9092,broker2:9092");
props.put("compression.type", "lz4");
props.put("batch.size", 65536); // 64KB 批次
props.put("linger.ms", 10); // 等待聚合
props.put("buffer.memory", 67108864); // 64MB
经验：压缩在高吞吐场景收益明显；CPU 紧张或消息极小（<几百字节）时可降低 batch 或取消压缩。5) 设置适当的生产者确认 acks原理：acks=1 追求速度，acks=all 追求持久性。props.put("acks", "all"); // 强持久性，需配合 min.insync.replicas
// 低延迟场景可用：props.put("acks", "1");
经验：关键交易流选择 acks=all + min.insync.replicas>=2；日志/监控流可选 acks=1 提升吞吐。6) 消费者 Fetch 调优原理：每次抓取的最小字节与最大等待影响吞吐与延迟。# consumer
fetch.min.bytes=1048576 # 1MB，增大以减少请求开销
fetch.max.wait.ms=50 # 最长等待以凑满批次
max.partition.fetch.bytes=8388608 # 每分区最大抓取
经验：延迟敏感业务降低 fetch.max.wait.ms；吞吐优先业务增大 fetch.min.bytes 与 max.partition.fetch.bytes。7) Socket 缓冲（网络层关键）原理：发送/接收缓冲影响突发流量可承载能力。# broker/server.properties
socket.send.buffer.bytes=262144
socket.receive.buffer.bytes=262144
# OS 层（Linux）建议上限
echo 'net.core.wmem_max = 134217728' | sudo tee -a /etc/sysctl.conf
echo 'net.core.rmem_max = 134217728' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
经验：结合 NIC 驱动与 MTU 调优；观察丢包/重传与队列长度，避免过度放大导致内存占用攀升。8) KRaft 元数据超时原理：KRaft 替代 ZooKeeper，选举与元数据请求的超时影响控制面稳定性。# broker/server.properties（KRaft 模式，具体参数名随版本差异）
controller.quorum.election.timeout.ms=5000
controller.quorum.request.timeout.ms=30000
经验：在网络抖动或控制器负载高时适当放宽；务必结合当前 Kafka 版本文档验证参数名与默认值。9) 多目录 log.dirs 优化磁盘 IO原理：多物理盘分散日志写入与读取，降低单盘瓶颈。log.dirs=/data/kafka-logs1,/data/kafka-logs2,/data/kafka-logs3
经验：保持盘间均衡与独立挂载；注意文件系统选型与磁盘调度器（SSD 建议 none/mq-deadline）。10) 复制因子 Replication Factor 与最小 ISR原理：复制因子提升容灾能力；min.insync.replicas 决定可写安全阈值。# 创建主题时指定复制因子
kafka-topics.sh --bootstrap-server
--create --topic payments --partitions 32 --replication-factor 3
# 强一致要求
min.insync.replicas=2
经验：一般生产建议 RF=3；跨机架部署配合机架感知，保障副本分布合理。监控与验证清单关键指标：request-rate/queue、records-per-request、bytes-in/out、replica-lag、fetch-latency、磁盘/网络利用率。端到端：生产-代理-消费延迟分解，定位瓶颈链路。回归测试：基准压测覆盖消息大小分布、峰值/平均 QPS、网络/磁盘抖动。变更策略：逐项调参、灰度发布、可回滚，记录版本与参数快照。个人实践经验（取舍原则）先“结构性并行”（分区数）再“局部高效”（批次与压缩）；避免只堆参数不改架构。写入安全三件套：acks=all + min.insync.replicas>=2 + RF>=3；有压测支撑再降级到 acks=1。抓取参数面向业务目标：低延迟用小批次、吞吐优先用大批次+等待。网络与磁盘是基础设施瓶颈，Kafka 参数只是“放大器”，必须与 OS/NIC/盘配置协同优化。参考资料Kafka 调优十招：https://mp.weixin.qq.com/s/RyPrlIps1tWUWgQcIyiEvw