Redis主从架构中主节点不会自动降级，真正的“自动降级”实为故障转移后原主恢复为从节点的过程，由Sentinel自动完成：监控、选举新主、通知客户端、并命令原主执行replicaof同步新主。
Redis 主从架构本身不支持主库“自动降级”——这个说法容易产生误解。准确来说，Redis 的主从设计中，主节点（Master）不会主动、自动地把自己“降级”为从节点；真正需要的是：当主节点故障时，让某个从节点自动升级为主节点，并让原主节点在恢复后自动重新成为从节点。这个过程叫故障转移（Failover），而实现“自动”的关键组件是 Redis Sentinel（哨兵）。
下面分三块讲清楚怎么做：
一、为什么不能靠主库自己“降级”？
- Redis 主节点没有内置机制主动放弃写权限、断开客户端连接、转为只读从节点；
- 手动执行
replicaof <new-master-ip> <port>是可行的，但属于运维操作，不是“自动”； - 若强行让主节点执行
replicaof，会导致写中断、数据不一致、客户端连接异常，风险极高。
所以，“主库自动降级”实际要解决的问题是：
✅ 主挂了 → 从自动顶上（升主）
✅ 原主恢复 → 自动同步新主、变回从（即“被降级”为从）
二、用 Sentinel 实现全自动主从切换与角色重置
Sentinel 是 Redis 官方推荐的高可用方案，它能：
- 监控主从健康状态
- 主节点宕机时，自动触发选举、提升一个从节点为新主
- 通知所有客户端新主地址（需客户端支持 Sentinel）
- 原主恢复后，自动将其配置为新主的从节点（这才是你想要的“自动降级”效果）
关键步骤：
- 部署至少 3 个 Sentinel 实例（避免脑裂）
- 每个 Sentinel 监控同一组主从实例（如 1 主 2 从）
- 配置
sentinel monitor <master-name> <ip> <port> <quorum> - 设置
sentinel down-after-milliseconds和sentinel failover-timeout等参数
原主恢复后，Sentinel 会自动向它发送命令：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli -h <old-master-ip> -p 6379 replicaof <new-master-ip> 6379
完成数据同步，并回归从角色——这一步就是你所说的“自动降级”。
三、应用层配合：避免写请求打到旧主
即使 Sentinel 完成切换，客户端若仍缓存旧主地址，就会写失败。因此需：
- 使用支持 Sentinel 的客户端（如 Jedis、Lettuce、redis-py 的 Sentinel 连接池）
- 客户端通过
sentinel get-master-addr-by-name动态获取当前主节点地址 - 写操作始终发往 Sentinel 返回的 master 地址，而非硬编码 IP
示例（Python + redis-py）：
from redis.sentinel import Sentinel
sentinel = Sentinel([('127.0.0.1', 26379)], socket_timeout=0.1)
master = sentinel.master_for('mymaster', socket_timeout=0.1)
master.set('key', 'value') # 自动路由到当前主四、替代方案：Redis Cluster（适合更大规模）
如果你用的是 Redis Cluster（非主从+Sentinel），故障转移由集群内部 Gossip 协议驱动，同样能做到：
- 主节点失联后，其从节点自动发起投票、升主
- 原主恢复后，自动以从节点身份加入集群，同步数据
- 但 Cluster 要求客户端支持重定向（MOVED/ASK），且 key 分片逻辑更复杂
不复杂但容易忽略：真正的“自动降级”，本质是系统级角色重分配，不是单点自我降级。靠 Sentinel 或 Cluster 才能闭环实现——手动脚本或定时任务无法保证一致性与时效性。
