Redis主从架构依赖Sentinel实现自动选主切换：通过心跳探测标记主观下线，投票达成客观下线，按复制偏移量、运行时长、优先级等规则选举新主，并执行SLAVEOF命令完成故障转移。
Redis 主从架构本身不支持自动选主切换，必须依赖外部高可用组件——最常用、最成熟的就是 Redis Sentinel（哨兵）。它不是 Redis 内置功能，而是一套独立运行的监控与故障转移系统。
哨兵如何完成自动选主切换
哨兵通过分布式协同机制实现客观判断和民主选举，整个过程无需人工干预：
-
持续心跳探测：每个哨兵每秒向所有 Redis 实例（主、从）发送 PING 命令；若在
down-after-milliseconds（如 5000ms）内无响应，标记该节点为“主观下线” -
投票确认故障：当某个哨兵判定主节点主观下线后，会向其他哨兵发起询问；若达到配置的
quorum数量（如 2/3 个）也认为主节点不可达，则触发“客观下线” -
从节点筛选与选举：哨兵组从所有在线从节点中，按规则选出最合适的候选者——优先选择复制偏移量最新、运行时间最长、优先级（
slave-priority）最高、ID 最小的从节点 -
执行故障转移：当选出新主后，一个哨兵作为 Leader 向该从节点发送
SLAVEOF NO ONE命令将其提升为主；再通知其余从节点执行SLAVEOF指向新主，并更新自身配置
关键配置项说明
哨兵的可靠性高度依赖合理配置，核心参数需协同设定：
-
sentinel monitor：定义被监控主节点及最低同意数，quorum应 ≤ 哨兵总数且建议 ≥ ⌈N/2⌉+1（如 3 哨兵设为 2） -
sentinel down-after-milliseconds：主观下线阈值，太短易误判，太长影响恢复速度，生产环境通常设为 3–30 秒 -
sentinel failover-timeout：故障转移总超时时间，需覆盖从节点同步、客户端重连等耗时，建议 ≥ 60 秒 -
slave-priority（在从节点 redis.conf 中设置）：数值越小优先级越高，可用于指定偏好提升的节点
部署与启动顺序要求
哨兵集群必须满足最小规模并遵循启动逻辑，否则无法达成共识：
- 最少 3 个哨兵节点，部署在不同物理机或可用区，避免单点故障导致无法投票
- 先确保主从复制已正常建立（
INFO REPLICATION显示role:slave且master_link_status:up） - 再依次启动哨兵进程：
redis-sentinel /path/to/sentinel.conf，不能同时启动全部，建议错开几秒 - 客户端必须连接哨兵地址（如
sentinel://host:26379），由哨兵返回当前主节点地址，而非直连固定 IP
验证切换是否生效
切换完成后，可通过以下方式快速确认结果：
- 查看哨兵日志：搜索
+failover-state-select-slave、+switch-master等关键字 - 登录任一哨兵执行：
SENTINEL masters查看当前主节点 IP 和端口 - 登录原主节点执行：
INFO REPLICATION，角色应已变为slave，且master_host指向新主 - 客户端重新获取主节点连接后，写入操作应能成功，且数据在新主上可查
