replica-serve-stale-data 控制主从断连后从节点是否响应读请求，默认 yes，返回断连前最后数据；设为 no 则对 GET 等只读命令返回 ERR MASTERDOWN 错误，不处理该错误将导致业务异常。
replica-serve-stale-data 是什么，它管哪部分请求
replica-serve-stale-data 控制的是：主从断连后，从节点是否继续响应读请求。它不干预写请求（从节点默认不接受写），只影响客户端发到从节点的 GET、HGET 等只读命令。
设为 yes（默认），从节点照常返回断连前最后同步到的数据；设为 no，所有读请求直接返回错误 MASTERDOWN Link with MASTER is down and slave-serve-stale-data is set to 'no'。
- 这个配置只在从节点生效，主节点上设置无效
- 修改后无需重启，
CONFIG SET replica-serve-stale-data yes/no立即生效 - 它不影响复制重连逻辑，只是“要不要接活”的开关
设成 no 之后，客户端实际会遇到什么错误
不是超时，也不是空响应，而是明确的协议级错误回复。Redis 客户端收到的是带 ERR 前缀的字符串，例如：
ERR MASTERDOWN Link with MASTER is down and slave-serve-stale-data is set to 'no'
不同语言客户端处理方式不同，但共性是：不会自动降级或重试，需要业务层捕获该错误并决策（比如切主、返回 503、走本地缓存）。
- Go 的
redis.UniversalClient会抛redis.Error，message 含MASTERDOWN - Python 的
redis-py抛ConnectionError，但异常 message 里有完整错误字符串 - Node.js 的
ioredis在error事件中 emit 此字符串，不是断连事件
为什么不能只靠这个配置实现强一致性读
即使设成 no，也不能保证读到最新数据。因为：replica-serve-stale-data 只判断“主从链路是否断”，不判断“数据是否已同步到最新”。主从网络延迟、主节点积压写命令、从节点复制缓冲区不足等情况，都可能导致从节点数据落后，但它仍处于“连接正常”状态，照样返回旧值。
- 想读最新数据，必须打到主节点，或用
READONLY OFF+REPLICAOF NO ONE（不推荐） - Redis Cluster 中，
replica-serve-stale-data对ASK/MOVED重定向无影响 - 开启
min-replicas-to-write或min-replicas-max-lag是另一层保障，和它无关
线上改配置前必须确认的三件事
很多故障源于没核对依赖项。改 replica-serve-stale-data 前，请盯住这三点：
- 客户端是否做了
MASTERDOWN错误的兜底——没处理就直接 panic 或 500，比返回旧数据更伤 - 监控是否采集了
master_link_status和master_last_io_seconds_ago，否则你根本不知道从节点啥时候开始“假连” - 是否启用了
tcp-keepalive，避免中间网络设备静默断连却不通知 Redis，导致replica-serve-stale-data判断失灵
这个配置本身很简单，难的是它暴露的是整个读链路的一致性假设是否成立。一旦主从延迟变大或断连频繁，yes 会悄悄返回旧数据，no 会突然大量报错——两种都不是“自动变好”的状态。
