Kafka 新同事上来就用Kafka，瑟瑟发抖

Kafka | 新同事上来就用Kafka，瑟瑟发抖

2025年7月，Apache Kafka 3.6正式发布，号称吞吐量提升20%，但“配置地狱”的江湖传说依然在程序员圈子里流传……

“新来的同事一上手就搞Kafka，我慌得一批”

上周公司来了个应届生，简历上写着“精通分布式系统”，老大一拍桌子：“正好！新项目用Kafka处理日志，你来搭环境吧。”小伙子二话不说，当天就提交了一版配置，我瞄了一眼他的YAML文件，手一抖，咖啡洒了一半——这兄弟直接照着Github上的“高性能模板”抄，连acks=all和min.insync.replicas=3都敢在生产环境里裸奔……

Kafka，新手村终极Boss

说实话，Kafka这玩意儿就像个带刺的玫瑰，你说它厉害吧？确实——百万级TPS、分布式持久化、流处理全家桶，哪个不是吊打传统MQ，但你要以为docker-compose up就能搞定，那就太天真了。

记得我第一次调优时，num.io.threads和num.network.threads设成CPU核数，结果直接OOM，后来才知道这俩参数是按socket算的，不是按物理核心啊！更别提那些藏在角落的坑：

• log.retention.hours设了24小时，但磁盘还是爆了？因为清理线程默认每小时才跑一次
• 消费者组莫名其妙rebalance？可能是session.timeout.ms和heartbeat.interval.ms没对齐
• 说好的“高可用”？unclean.leader.election要是设成true，分分钟数据消失给你看

“高性能”背后的玄学

新同事信誓旦旦：“我压测过了，单机10W QPS！”结果上线第一天，Producer就开始疯狂重试，一查监控——好家伙，request.timeout.ms=30000配了30秒，客户端线程全阻塞了，这时候才想起Kafka官网角落里那句话：“默认参数适合测试环境”（翻译：生产环境用默认值？你完了）。

老司机都知道，真正的战斗从你第一次遇到NotEnoughReplicasException才开始：

1. 先看ISR列表是不是有副本掉队了
2. 再查ZooKeeper（对，2025年了还得和这老古董打交道）的/brokers/topics状态
3. 最后发现是某个Broker的磁盘IOPS被监控进程吃光了……

给勇者的生存指南

如果你也遇到“Kafka勇士”，不妨塞给他这份保命清单：

1. 先画拓扑图：Broker、ZooKeeper、Producer/Consumer分布在哪些机器？跨机房了吗？
2. 监控埋全套：别只看吞吐量，UnderReplicatedPartitions、RequestQueueSize才是隐藏BOSS
3. 模拟作死：主动kill -9 Broker，拔网线，看看客户端重试策略能不能扛住
4. 备好逃生舱：retries=Integer.MAX_VALUE？记得配合max.block.ms，不然小心内存爆炸

现在那新同事正蹲在机房查日志，背后贴着“Kafka幸存者”的便签纸，我递了杯咖啡过去：“兄弟，知道为什么Kafka图标是只豹子吗？因为配置它的人，都得有点豹子胆。”

（注：文中配置项均为真实参数，但请勿直接套用——你的业务场景可能比我的段子更刺激）