RF=3、MinISR=3 看似"写三份才算成功最安全"，实则零容错——任何一个 broker 重启就全面写入中断。本文记录从 AWS Health 告警发现到零停机修复的五步完整过程，附一键检测脚本。前言某天巡检 AWS Health Dashboard，弹出一条红色告警：AWS_KAFKA_HIGH_RISK_CONFIG_RF_EQUALS_MINISR One or more topics have a MinISR configuration that can lead to write/read failures and requires your immediate action.第一反应："RF=3 三副本应该没问题吧？"排查后才发现min.insync.replicas也是 3——意味着 3 个副本全部在线才能写入。而两天后就有一次 MSK 安全补丁（逐 broker 滚动重启），不改就必然写入中断。本文适合：使用 AWS MSK 或自建 Kafka 的运维/SRE、想理解 RF 和 MinISR 关系的后端开发、需要快速排查和修复 Kafka 高可用配置的团队。一、RF 和 MinISR 到底是什么关系核心概念速查
