主节点宕机后需快速、安全恢复写能力，核心是提前规避单点风险：必须开启RDB+AOF双持久化、部署≥3个哨兵实例、合理设置从节点优先级；宕机后若哨兵失效，须人工选定offset最大的从节点执行slaveof no one升主，并用其最新RDB覆盖原主再重启，防止雪崩式数据丢失。
主节点宕机不是“能不能扛住”的问题，而是“怎么扛得稳、不丢数据、不乱状态”的问题。核心在于提前规避单点风险，同时确保故障发生时能快速、安全地恢复写能力。
主节点宕机前必须做的三件事
很多数据丢失事故，其实发生在宕机之前——配置没设好，哨兵没配全，持久化没开。
-
开启 RDB + AOF 双持久化：仅靠 RDB 可能丢几分钟数据，仅靠 AOF 性能压力大。推荐配置
appendonly yes+save 900 1（900秒内至少1次变更就触发快照），并设置appendfsync everysec平衡安全性与性能。 - 部署至少 3 个哨兵实例：单哨兵极易误判（比如网络抖动）。3 个哨兵可容忍 1 个失效，且投票需 ≥2 票才判定主节点下线，大幅降低脑裂和误切风险。
-
给从节点合理设置优先级：在从节点配置中加上
slave-priority 10（数值越小优先级越高），避免自动选主时挑到低配或同步滞后的机器。
主节点宕机后手动应急流程（无哨兵或哨兵失效时）
不能等系统自动恢复，尤其在哨兵未生效或配置异常时，需人工介入保服务。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 确认一个数据最新、运行稳定的从节点（查
redis-cli -p 6380 info replication | grep slave_repl_offset，选 offset 最大的）； - 连上该从节点，执行
slaveof no one，它立即获得写权限，可接管业务写入； - 对这个新主节点执行
save或bgsave，生成最新 RDB 文件； - 将该 RDB 拷贝覆盖原主节点的 data 目录，再启动原主节点；
- 原主节点启动后，用
slaveof 新主IP 新主端口将其设为从节点，开始同步。
为什么不能直接重启原主节点？
如果原主节点没开持久化，重启会清空内存并从空 RDB 加载——结果是整个集群变为空库，所有从节点也会跟着同步成空数据。这就是典型的“雪崩式数据丢失”。必须先从从节点捞出最新数据，再喂回去。
进阶防护：避免分布式锁失效
主从架构下，普通 SETNX 加锁 + 主节点宕机 → 从节点升主 → 锁丢失 → 多个客户端同时持锁，这是高危场景。
- 不要依赖单个 Redis 实例做分布式锁；
- 改用 Redlock：部署 ≥3 个相互独立的 Redis 主节点（无主从关系），加锁时向全部节点请求，成功 ≥2 个才算加锁成功；
- 释放锁时，也需逐个尝试删除，不因某节点失败而中断整体释放逻辑。
