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 到底是什么关系
核心概念速查
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/u012172506/article/details/163573635
