Redis 主从切换是保障高可用的核心机制，但很多开发者在使用哨兵（Sentinel）或 Cluster 时都遇到过切换后数据丢失的问题。不少人第一反应是“Redis 不可靠”，但事实上，绝大多数数据丢失都源于对异步复制模型的理解偏差，以及配置参数与业务场景不匹配。本文将从复制原理出发，逐一拆解主从切换时数据丢失的典型场景，并给出可落地的规避方案。
一、先理解根因：Redis 复制是异步的
Redis 主从复制默认采用异步复制。主节点处理完写命令后，立即向客户端返回成功，然后再将命令异步发送给从节点。这意味着：
- 主节点确认写入成功时，从节点可能还没收到这条命令；
- 如果主节点在此刻宕机，这条命令就永久丢失了。
这是所有切换丢数据问题的底层原因。后续的各种场景，本质上都是这个异步窗口在不同条件下的放大或触发。
二、典型丢失场景拆解
场景 1：主节点宕机，从节点数据滞后
这是最常见的情况。假设主节点写入 1000 条数据，从节点只同步到 990 条，此时主节点宕机，哨兵选举从节点为新主，那 10 条数据就丢了。
关键参数：
min-slaves-to-write（Redis 5.0 后为min-replicas-to-write）：主节点至少要有 N 个从节点确认，才允许写入；min-slaves-max-lag（min-replicas-max-lag）：从节点延迟超过 N 秒，主节点拒绝写入。
如果这两个参数不配置，主节点会“来者不拒”，异步窗口内的数据必然面临丢失风险。
规避思路：
min-replicas-to-write 1
min-replicas-max-lag 10
这样当从节点延迟过大或数量不足时，主节点直接拒绝写入，牺牲可用性换取数据安全。业务侧需要接受“写入失败”并做降级处理。
场景 2：脑裂导致双主写入
网络分区时，原主节点与哨兵、从节点失联，哨兵在从节点侧选举出新主。但原主节点可能仍然存活，客户端继续向它写入数据。等网络恢复，原主节点被降级为从节点，它会清空自身数据并从新主全量同步，脑裂期间写入原主的数据全部丢失。
规避思路：
同样依赖 min-replicas-to-write。当原主节点发现无法连接到足够数量的从节点时，会拒绝客户端写入，从而避免脑裂期间产生“孤立写入”。
场景 3：从节点晋升时数据未完全同步
哨兵选举新主时，会挑选数据最完整的从节点。但如果多个从节点延迟相近，哨兵可能选到一个相对滞后的节点。更极端的情况是，新主晋升后，其他从节点会向它发起全量或部分同步，如果新主自身数据就不完整，整个集群的数据基线就被拉低了。
规避思路：
- 合理设置
repl-backlog-size，增大复制积压缓冲区，提高部分同步成功率； - 监控各从节点的
master_repl_offset，确保延迟在可接受范围内； - 哨兵配置
sentinel down-after-milliseconds不宜过小，避免误判导致频繁切换。
场景 4：WAIT 命令使用不当
Redis 3.0 引入了 WAIT 命令，可以阻塞等待指定数量的从节点确认。但很多人误以为用了 WAIT 就万无一失。
实际上：
WAIT只保证命令到达从节点，不保证从节点已持久化；- 如果从节点随后宕机且未持久化，数据仍可能丢失；
WAIT增加延迟，高并发下可能成为瓶颈。
正确用法： 对数据安全性要求极高的写操作，可以配合 WAIT 1 100（等待至少 1 个从节点确认，超时 100ms），但必须接受延迟增加。
场景 5：持久化配置不当放大丢失
如果主从节点都关闭了 AOF，仅依赖 RDB，切换时新主可能基于较旧的 RDB 恢复，丢失更多数据。即使开启 AOF，appendfsync everysec 模式下最多也可能丢失 1 秒数据。
规避思路：
- 主从节点均开启 AOF，设置
appendfsync everysec（平衡性能与安全）； - 对数据安全要求极高时，可考虑
appendfsync always，但性能下降明显； - 确保
auto-aof-rewrite-percentage合理，避免 AOF 文件过大导致恢复缓慢。
三、如何系统性降低丢失风险
| 措施 | 作用 | 代价 |
|---|---|---|
| 配置 min-replicas-to-write | 防止主节点孤立写入 | 降低可用性 |
| 合理设置 repl-backlog-size | 提高部分同步成功率 | 内存占用 |
| 监控复制延迟 | 及时发现滞后 | 需运维投入 |
| 开启 AOF everysec | 减少持久化丢失 | 少量性能损耗 |
| 业务侧幂等 + 补偿 | 兜底数据一致性 | 开发复杂度 |
四、面试答题要点
如果面试中被问到“Redis 主从切换为什么会丢数据”，可以按以下逻辑回答：
- 根因：Redis 复制是异步的，主节点写入成功不代表从节点已同步；
- 场景：主节点宕机、脑裂双写、从节点滞后、WAIT 使用不当、持久化配置不当；
- 参数：
min-replicas-to-write、min-replicas-max-lag、repl-backlog-size、appendfsync； - 方案：没有银弹，需在可用性与一致性之间权衡，配合业务侧幂等和补偿；
- 延伸：如果要求强一致，应考虑 Redis Cluster 的
WAIT或改用其他存储（如 etcd、ZooKeeper 等 CP 系统）。
五、总结
Redis 主从切换丢数据不是 bug，而是异步复制模型下的必然 trade-off。理解这一点后，我们就能根据业务对一致性的要求，选择合适的参数配置和架构方案。对于大多数互联网业务，配置 min-replicas-to-write + 开启 AOF + 业务幂等，已经能覆盖绝大部分场景。而对于金融级强一致需求，则应考虑引入外部协调服务或选择 CP 型存储，而不是强行让 Redis 承担它不擅长的角色。
未经允许不得转载：任鹏个人博客 » Redis 主从切换时数据丢失的场景分析
