我会先确认影响范围，同时控制故障继续放大。理解副本同步集合、确认条件、故障选举和可用性与可靠性的权衡。每个分区由 Leader 处理读写，Follower 拉取并复制日志。AR 是所有副本，ISR 是当前与 Leader 保持足够同步的副本集合。Leader 故障后，控制器优先从 ISR 选举新 Leader，以降低已确认消息丢失风险。 生产者使用 acks=all 时，Leader 需满足最小同步副本条件才接受写入；ISR 数量不足会让写入失败，以牺牲可用性保护可靠性。

止损之后，我会按请求链路建立证据，而不是凭经验猜。沿着「Leader 接收写入 → Follower 持续拉取 → 满足条件留在 ISR → Leader 故障触发选举 → 新 Leader 恢复服务并截断分叉」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 Leader 接收写入 分区 Leader 负责读写，生产者与消费者通过元数据找到当前 Leader。 Follower 持续拉取 Follower 从 Leader 复制日志，复制速度和网络决定落后程度。 KafkaController/QuorumController：分区选举。 kafka-metadata-quorum.sh：控制器仲裁状态。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

定位时我最关注这些参数、指标和容量关系。是否区分 Leader、Follower、AR 和 ISR。 能否解释 acks=all 与 min.insync.replicas 的组合。 是否理解不安全选举在可用性和数据丢失之间的取舍。

找到根因后先做最小修复，再用同样的流量验证。三副本实际都落在同一机架，机架断电后无可用 ISR。配置副本数没有解决故障域问题；启用 rack awareness 并校验副本分布后才能承受整机架故障。 副本数足够但故障域集中：ISR 数量：副本跨故障域。 ISR 长期收缩未告警：UnderReplicatedPartitions：监控 ISR 收缩。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「ISR shrink」为主基线，记录值应满足「记录分区基线」；同时保存 ISR 数量、UnderReplicatedPartitions，使后续变化能够回到同一时间轴比较。

恢复阶段要逐步放量，最后把监控和边界补齐。方案：更适合的场景：主要收益：代价与边界。 unclean election=false：核心数据不能接受已确认丢失：只从 ISR 选主：全部 ISR 不可用时分区不可用。 unclean election=true：可用性优先且数据可重建：更快恢复服务：可能丢数据并产生历史截断。 多机架 ISR：需承受故障域损失：副本真正隔离：跨机架带宽与延迟成本。