min-slaves-to-write和min-slaves-max-lag必须同时配置，缺一不可，共同构成主节点健康自检开关：前者限制最低在线从节点数（建议≥⌊n/2⌋+1），后者限定最大复制延迟（建议8–10秒），任一不满足即拒绝写入。
min-slaves-to-write 和 min-slaves-max-lag 必须同时配，缺一不可
这两个参数是 Redis 主节点主动拒绝写入的“双保险”，不是可选开关。只要其中一个不满足，min-slaves-to-write 就会失效——比如你设了 min-slaves-to-write 3 却没配 min-slaves-max-lag，主节点在从节点全部延迟超 60 秒时仍照常收写请求，脑裂风险一点没降。
实际配置建议按从节点总数动态设：min-slaves-to-write 至少设为 ⌊N/2⌋ + 1（N 是从节点数），min-slaves-max-lag 控制在 8–10 秒内。例如 5 个从节点，就配 min-slaves-to-write 3 和 min-slaves-max-lag 8。
- 别用固定值如
min-slaves-to-write 1：单个从节点存活就放行，等于没防 -
min-slaves-max-lag不是 ping 延迟，而是从节点上报 ACK 的 lag，得看INFO replication里的slaveX.repl_ack_log - Redis 7.0 默认不启用这两个参数，必须显式写进
redis.conf或启动时用--appendonly yes类似方式传参
哨兵 down-after-milliseconds 不能沿用旧版默认值
Redis 7.0 哨兵默认的 down-after-milliseconds 30000 在高可用场景下太宽松。网络抖动持续 3–5 秒就可能触发误判，尤其在容器或云环境里，CPU 抢占、内核调度延迟都容易让心跳包晚到。
应调低至 5000–8000，并同步调整 quorum：3 个哨兵设 quorum 2，5 个哨兵设 quorum 3。否则会出现“多数哨兵认为主还活着，但少数已发起切换”的撕裂状态。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 调低
down-after-milliseconds后，必须验证客户端重连逻辑是否扛得住频繁拓扑刷新 - 别忘了设
failover-timeout（建议 180000），防止某个从节点同步卡住拖长整个切换周期 - Redis 7.0 的
sentinel monitor命令支持ip:port显式指定哨兵监听地址，避免因容器网络 NAT 导致心跳丢失
集群模式下 cluster-require-full-coverage 要关掉
Redis Cluster 默认开启 cluster-require-full-coverage yes，意思是只要有一个哈希槽不可用，整个集群就拒绝所有请求。这在脑裂恢复阶段反而放大问题：旧主降级为从后同步 RDB 期间，部分槽点处于 migrating/importing 状态，若该参数开着，客户端会收到 CLUSTERDOWN 错误，而不是静默重试。
生产环境应设为 no，配合客户端 SDK 的自动重试 + 槽映射刷新（如 Lettuce 的 ClusterTopologyRefreshOptions）来应对短暂不可用。
- 关掉后，要确保监控覆盖
cluster_stats_messages_sent和cluster_stats_messages_received，及时发现分区未愈合 - Redis 7.0 的
CLUSTER NODES输出新增了fail?<epoch></epoch>字段，可用来判断节点是否被标记为疑似失败而非永久下线 - 别依赖
cluster-require-full-coverage当兜底——它解决不了脑裂，只掩盖症状
客户端连接池必须处理 MASTERDOWN 和 READONLY 错误
Redis 7.0 在脑裂窗口期返回的错误码很关键：MASTERDOWN 表示当前节点已非主，READONLY 表示节点是只读从库却收到了写请求。客户端如果只是简单重试原连接，就会持续打在旧主或从库上，加剧数据错乱。
正确做法是：捕获这两个错误后，强制刷新集群拓扑（调用 CLUSTER SLOTS 或 CLUSTER NODES），重建连接池，并丢弃当前请求（不重试）。Lettuce 和 Jedis 3.0+ 都支持自动拓扑刷新，但默认关闭。
- Lettuce 需启用
ClusterTopologyRefreshOptions.builder().enableAllAdaptiveRefreshTriggers() - Jedis 3.9+ 要设置
new JedisCluster(..., new ClusterConfig().setRefreshPeriod(3000)) - 自研客户端务必检查
redis-cli -c模式下的重定向行为是否被复刻，否则会绕过集群智能路由
