在 CentOS 上优化 Kafka 的可落地清单
一 系统层优化
- 资源与内核参数
- 建议关闭或严格限制 Swap（生产可设 vm.swappiness=1，极端场景直接 swapoff -a），避免页交换影响延迟与吞吐。
- 提升文件句柄与进程数：/etc/security/limits.conf 中设置 * soft/hard nofile 1048576，* soft/hard nproc 65536，并确认 systemd 服务段 LimitNOFILE 同步设置。
- 网络与连接：net.core.somaxconn=65535、net.core.netdev_max_backlog=250000、net.ipv4.tcp_max_syn_backlog=4096、net.ipv4.ip_local_port_range=10240 65535、net.ipv4.tcp_tw_reuse=1、net.ipv4.tcp_fin_timeout=15。
- 脏页与回写：vm.dirty_background_ratio=5、vm.dirty_ratio=70，减少长停顿；必要时开启适度的 swap 作为兜底仅在极端 OOM 场景。
- 文件系统与挂载：日志目录建议使用 XFS/EXT4，并挂载 noatime；多盘场景将不同磁盘路径加入 log.dirs 以分散 I/O（如 /disk1/kafka-logs,/disk2/kafka-logs）。
- 说明：如业务不使用 IPv6，可禁用以避免额外栈带来的开销。
二 JVM 与 GC 调优
- 堆大小与容器协调：生产建议堆 4–8 GB 起步，且 -Xms 与 -Xmx 等值（避免运行期扩缩堆带来停顿抖动）；在容器/受限内存环境，确保容器内存上限 > 堆内存，为堆外与 OS page cache 预留空间。
- 垃圾回收器：优先使用 G1 GC，如 -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35；在 64 GB 内存的节点，堆 5–8 GB 通常更利于低停顿与稳定 GC。
三 Broker 关键配置
- 基础网络与 I/O
- listeners=PLAINTEXT://0.0.0.0:9092（或 SASL/SSL 按安全策略配置）；num.network.threads≈CPU 核数+1；num.io.threads≈CPU 核数×2（一般不超过×3）；socket.send/recv.buffer.bytes=1 MB；socket.request.max.bytes=100 MB（按业务调大以容纳大消息/批量）。
- 存储与多盘
- log.dirs 配置多块磁盘目录，分散分区与段文件，提升并发写吞吐与降低寻道开销。
- 复制与可用性
- default.replication.factor=3；min.insync.replicas=2；replica.lag.time.max.ms=10000（按 SLA 适度收紧/放宽）。
- 分区与并发
- 主题分区数按下游并发与磁盘数规划；分区是并发单位，但过多分区会增加 ZooKeeper/Kafka 元数据与控制器压力，需权衡。
- 消息大小与副本抓取
- 如存在大消息（>1 MB），同步调大 message.max.bytes 与 replica.fetch.max.bytes，避免副本同步失败与 ISR 收缩。
四 日志保留与刷盘策略
- 清理策略与段大小
- 常规主题用 delete 策略：log.retention.hours=72（或按业务改为 ms/bytes 控制）；低流量主题建议同时设置 log.segment.bytes=1 GB 与 log.segment.ms（如 12 小时）以便按时触发清理；检查间隔 log.retention.check.interval.ms=300000（5 分钟）；真正删除前延迟 log.segment.delete.delay.ms=60000（1 分钟）。
- 变更/状态类主题用 compact 策略（cleanup.policy=compact），同一 Key 保留最新值，节省空间并利于“读最新状态”。
- 刷盘策略
- 官方不建议在 Broker 端通过 log.flush.interval.messages/ms 强制刷盘（会显著降吞吐）；可靠性由 副本机制保障。如需更强持久化可按需适度调小，但务必先在测试环境评估。
五 监控 验证与常见坑
- 监控与告警
- 开启 JMX（如 JMX_PORT=8060），结合 Prometheus + JMX Exporter + Grafana 监控吞吐、请求耗时、请求队列、网络/磁盘、GC 次数与停顿、UnderReplicatedPartitions、ISR 收缩、请求错误率等；ZooKeeper 延迟/超时需重点观测。
- 客户端侧协同
- 生产者：启用批量与压缩（如 linger.ms、batch.size、compression.type=snappy/lz4/zstd），合理设置 acks（all 提升可靠性但降吞吐）；消费者：适当增大 fetch.min.bytes/fetch.max.wait.ms 提升批处理效率。
- 常见坑与修复
- “打开文件过多”报错：提升 ulimit -n 与 systemd LimitNOFILE，并确认进程实际生效值（cat /proc//limits）。
- 大消息副本不同步：同步增大 message.max.bytes 与 replica.fetch.max.bytes，避免 ISR 频繁掉队。
- 低流量主题迟迟不清理：同时设置 log.retention.hours 与 log.segment.ms，确保能按时滚动与清理。
- 过度强制刷盘：移除/放宽 log.flush 参数，依赖副本与 OS page cache 获取更高吞吐。
