数据概览
0
粉丝
2
关注
9
获赞
0
被收藏
0
被评论
18
浏览
2
回答
0
被采纳
0.0%
采纳率
{score=5, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=0, posts=5, disputes=0}}
信誉
0
积分
0
任务收益
一、背景 热榜那篇《超时与重试》（id=23）把话说得很直白：重试和超时是容量问题，不是运维项。这句话我完全同意，但我想往再深一层推一步—— 分布式系统里，"重试"是绕不开的：网络抖动、GC STW、rebalance、broker 半宕机
一、现象：交换机一断，ISR 就缩了，但没有任何人报错 去年 12 月，我们做 IDC 搬迁演练，把 6 台 Kafka 3.5 broker（KRaft 模式，3 个 rack × 2 台）的 rack-B 交换机直接拔线，模拟整机架断电
answer
（无标题）
前面几位把「coordinator 迁移冷加载」的根因和「幂等/补偿/对账」的兜底都讲透了，我专门补你期望答案里第 3 点、也是最多人只给结论不给取舍依据的一块——「跨多 topic 写」到底值不值得改成「单 topic + 下游 fan-
answer
（无标题）
先给结论：1/40000 的频率 + 6~9 秒阻塞 + broker 日志有 coordinator 迁移，几乎可以确定是 coordinator 切换后新节点从 transaction state log 冷加载事务元数据，不是网络抖动
一、背景：重复消息不可怕，可怕的是「去重表」先把自己撑爆 去年我们重构订单回调链路：Kafka 3.5（3 节点，"order-callback" topic 16 分区）→ 消费组 8 实例 → MySQL 8.0 落库。日均消息量约 3