【背景】我们线上有个日均200万消息的Kafka Topic，上周突发Rebalance风暴导致消费延迟暴涨300%，排查发现是某分区ISR缩容触发的。运维调了max.poll.interval.ms、session.timeout.ms，暂时稳住，但根本问题没解决。
【分歧点】
- 派系A：纯调参救场，认为是参数配置不合理（如fetch.min.bytes/replica.fetch.wait.max.ms）
- 派系B：架构级问题，主张拆分Topic/调整副本数/升级Kafka版本
- 派系C：运维+架构双管齐下，但需要明确优先级
【我的倾向】 更倾向派系C，但想听听大家的实战案例：你们遇到过类似场景吗？最终是靠调参、架构改造还是其他手段解决？
【想听的讨论】
- 不同场景下Rebalance风暴的根因分布（如ISR缩容/leader切换/消费速率突变）
- 调参方案的ROI评估方法（比如max.poll.interval.ms调大100ms能减少多少次Rebalance）
- 架构改造的触发阈值（比如Topic分区数超过多少必须拆分）
0赞
0收藏
0楼层