redlock在主从切换时因异步复制导致锁失效：客户端a在主节点加锁成功后，锁未同步至从节点，主节点宕机触发failover，该从节点升为新主，客户端b向新主加锁成功，造成双客户端持锁。

异步复制导致锁失效的典型场景

Redis主从复制默认是异步的，SET key value NX PX timeout 成功返回后，主节点并不等待从节点确认就直接响应客户端。如果此时主节点宕机、从节点晋升为新主，而锁尚未同步过去，客户端B就能在新主上再次成功执行相同命令——两个客户端同时持有同一把锁。这不是理论风险，而是可复现的数据一致性破坏事件。

配置 min-slaves-to-write 和 min-slaves-max-lag 能否真正兜底

这两个参数确实能限制写入：当存活从节点数不足或延迟超过阈值时，主节点拒绝写请求。但要注意：

• min-slaves-to-write 必须配合 min-slaves-max-lag 才有效，单独设置前者无意义
• 延迟单位是秒，min-slaves-max-lag 10 表示允许最多10秒复制滞后，对金融类秒级强一致场景仍不可接受
• 该机制只作用于主节点写入路径，不影响已发出但未同步的命令（比如主节点崩溃前刚写入、还未发给从节点的那批命令）

为什么 slave-serve-stale-data yes 会加剧读不一致

这个默认配置让从节点在网络断开或复制延迟时继续提供旧数据。问题在于：它和异步复制叠加后，客户端可能读到既“过期”又“不完整”的状态。例如：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 主节点已删除某个 key，但该 DEL 命令还没同步到从节点
• 从节点仍返回该 key 的旧值，且 EXPIRE 时间也未更新
• 业务逻辑误判资源可用，触发并发写入

若业务要求读取结果必须反映最新写入，应设为 slave-serve-stale-data no，但代价是从节点在同步卡顿时直接拒绝读请求。

真正影响决策的是复制积压缓冲区大小

repl-backlog-size 决定了断线重连时能否走部分复制（PSYNC）。如果设置太小，网络抖动后从节点被迫全量同步，期间复制延迟飙升，窗口期变长。建议按写入吞吐估算：每秒写命令数 × 预期最大断连时间 × 平均命令大小。实际中常设为 100MB 起，而非默认的 1MB。

异步复制本身无法消除，只能控制影响范围。关键不是“要不要用主从”，而是清楚知道哪类操作能容忍延迟、哪类必须绕过从节点直连主库——比如分布式锁的获取和释放，永远不该走从节点。