Kafka配置项常见误区与正确姿势
一 存储与目录配置
- 将log.dir当成多路径使用，导致容量与并发能力受限；应使用log.dirs配置多个数据目录（逗号分隔），以分散I/O、提升吞吐与容错。错误示例：log.dir=/data1；正确示例：log.dirs=/data1,/data2。
- 误以为“磁盘越多越好”，导致线程与CPU压力激增；更稳妥的做法是每个节点的挂载盘数控制在≤ CPU逻辑核数/2，并优先采用RAID10/RAID5，单个RAID逻辑盘不超过8块。
- 过度延长数据保留时间（如保留1年），会带来文件句柄与存储压力；通常按容量与SLA评估，默认7天更稳妥。
- 单盘/单目录承载过高分区数，增加调度与I/O抖动；应结合节点数、磁盘数与负载综合评估分区规模。
二 可靠性相关配置
- 生产者将acks=1或acks=0当作“高吞吐”手段，遇到Leader切换或副本未同步会造成消息丢失；关键链路应使用acks=all配合Broker端min.insync.replicas提升持久性。
- 关闭enable.idempotence且开启重试，网络抖动会引发重复消息；应启用幂等（enable.idempotence=true），必要时配合重试与退避策略。
- 重试与并发控制不当导致乱序：未启用幂等时，若max.in.flight.requests.per.connection > 1且发生重试，可能打乱顺序；启用幂等后可将并发控制在5以内以兼顾吞吐与顺序。
- Topic副本因子过低（如replication.factor=1），单点故障即丢数据；生产环境建议≥3，并将min.insync.replicas=2与acks=all组合使用。
三 生产者与消费者性能配置
- 沿用默认“逐条发送”，未利用批处理与压缩，吞吐受限；应适度设置linger.ms（如 5–20ms）与batch.size（如 16KB–128KB），并开启compression.type（snappy/lz4/zstd）。
- 缓冲区过小或阻塞处理不当，出现“send阻塞/超时”；可按公式buffer.memory ≈ batch.size × 分区数 × 2扩容，并合理设置max.block.ms。
- 消费者max.poll.records过大导致处理超时与频繁再均衡；应结合业务处理时长，适度降低单次拉取量，并相应调整max.poll.interval.ms。
- 过度追求“分区越多越快”，导致ZooKeeper/Kafka元数据与调度压力上升；应围绕节点数、磁盘数与消费者并发度综合评估，避免无限制扩容。
四 网络、ZooKeeper与KRaft及运维配置
- listeners与advertised.listeners配置不当，外部无法访问或返回错误地址；应确保内外网地址、端口与协议一致，必要时显式设置 advertised.listeners。
- zookeeper.connect书写错误（如每个ZK节点都加不同chroot），导致集群无法正确隔离或连接异常；正确做法是统一chroot路径：zk1:2181,zk2:2181,zk3:2181/kafka。
- 忽视防火墙/安全组与端口冲突，导致节点间通信失败；需放通9092/2181等端口并排查冲突。
- 仍使用ZooKeeper模式而未评估KRaft（Kafka Raft Metadata），在版本**2.8+**后可采用KRaft简化部署与运维。
- 未调整文件描述符与JVM参数，高并发下出现“Too many open files”或GC抖动；建议将ulimit -n ≥ 65536，JVM堆设置为**物理内存的1/4左右（如4–8GB）**并使用G1GC。
五 主题与数据大小配置
- 频繁创建/删除Topic，给ZooKeeper带来压力并可能阻塞删除流程；应减少随意建删，按业务域合并Topic，必要时采用灰度与生命周期管理。
- 将Kafka当“数据库”长期使用超大保留期或过大segment，引发句柄与资源压力；应基于磁盘容量与SLA设置log.retention.hours/bytes与segment.bytes，默认7天更稳妥。
- 消息体过大（如**>5MB**）会带来网络、内存与稳定性风险；建议业务侧切分或压缩，单条控制在≤1MB（生产端常见上限），必要时启用压缩并注意CPU开销。
- 误以为“同一个Topic天然有序”；应理解分区内有序，通过key或分区策略将需要顺序的消息路由到同一分区。