Redis集群在生产环境中一旦出现节点故障，如果没有完善的故障转移机制和哨兵监控体系，轻则服务短暂中断，重则数据丢失、业务全面瘫痪。Redis Sentinel（哨兵）就是专门解决这个问题的高可用方案——它实时监控主从节点状态，主节点挂了自动选举新主节点并通知客户端切换，整个过程通常在几十秒内完成。而Redis Cluster集群模式则通过分片和Gossip协议实现自动故障转移，两者配合使用才是分布式数据库高可用的完整答案。
一、Redis Sentinel哨兵机制的核心原理
Redis Sentinel本质上是一个独立运行的进程，它不存储数据，只做一件事：监控。它通过定期向Redis节点发送PING命令来判断节点是否存活，同时监听节点之间的复制关系。一个典型的Sentinel部署至少需要三个哨兵实例，形成仲裁机制，避免单点故障导致误判。
Sentinel的工作流程可以拆解为四个关键步骤：第一，监控（Monitoring）——持续检测主节点和从节点的运行状态；第二，通知（Notification）——当节点状态异常时，向管理员或其他系统发送告警；第三，自动故障转移（Automatic Failover）——主节点不可用时，从从节点中选举一个新主节点；第四，配置提供者（Configuration Provider）——客户端连接Sentinel获取当前主节点地址。
二、Sentinel的配置与部署实战
部署Sentinel非常简单，每个哨兵实例只需要一个配置文件。以下是一个标准的sentinel.conf配置示例：
port 26379 daemonize yes logfile "/var/log/redis/sentinel.log" sentinel monitor mymaster 192.168.1.100 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1
这里面几个参数非常关键：sentinel monitor定义了要监控的主节点名称、IP、端口和法定人数（quorum）。quorum设为2意味着至少需要两个哨兵同意主节点下线，才会触发故障转移。down-after-milliseconds设为30000表示30秒内没有响应就判定为主观下线（SDOWN），再结合其他哨兵的判断达成客观下线（ODOWN）。failover-timeout是故障转移超时时间，超过这个时间还没完成转移就会重新尝试。
三、故障转移的完整选举过程
当主节点被判定为客观下线后，Sentinel会启动故障转移流程。首先，由一个Sentinel Leader（通过Raft协议选出）发起转移。然后它从所有从节点中挑选一个新主节点，选择标准依次是：优先级（slave-priority）、复制偏移量（offset）、运行ID（runid）。优先级相同看谁数据最全，数据相同看谁的runid字典序最小。
选举出新主节点后，Sentinel会向其他从节点发送SLAVEOF命令，让它们指向新的主节点。同时，Sentinel会通过PUBLISH机制向所有监听该频道的客户端发送消息，通知主节点地址变更。客户端收到消息后重新连接新主节点，整个切换过程对业务来说是透明的。
四、Redis Cluster集群模式的故障转移机制
如果说Sentinel是主从架构的高可用方案，那Redis Cluster就是分片架构的高可用方案。Cluster把数据分成16384个哈希槽（hash slot），每个主节点负责一部分槽位。当某个主节点故障时，它负责的槽位会自动迁移到其他存活的主节点上。
Cluster的故障检测依赖Gossip协议，节点之间每秒交换一次PING/PONG消息。如果一个主节点在cluster-node-timeout时间内（默认15秒）没有响应，其他节点会将其标记为PFAIL（疑似下线）。当超过半数主节点都认为它下线时，就标记为FAIL（确认下线），此时触发槽位迁移。
槽位迁移的具体过程是：故障主节点的某个从节点会被提升为主节点，接管原来主节点的全部槽位。这个过程通过FAILOVER命令完成，其他节点收到命令后更新自己的槽位映射表。需要注意的是，如果故障主节点没有从节点，那它负责的槽位就会暂时不可用，直到人工介入。
五、哨兵监控的关键指标与告警策略
光部署了Sentinel还不够，必须建立完善的监控体系。核心监控指标包括：主节点是否在线、从节点复制延迟（replication delay）、Sentinel自身的存活状态、故障转移次数、连接数变化趋势。这些指标可以通过Sentinel的INFO命令获取，也可以通过Prometheus + Redis Exporter采集。
告警策略建议分层设置：第一层，主节点主观下线立即告警，通知运维介入排查；第二层，客观下线触发故障转移时告警，确认自动切换是否正常；第三层，如果故障转移失败或超时，升级为紧急告警。同时要监控Sentinel本身的健康状态，因为如果所有Sentinel都挂了，高可用机制就形同虚设。
# 查看Sentinel状态的常用命令 redis-cli -p 26379 SENTINEL masters redis-cli -p 26379 SENTINEL slaves mymaster redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster redis-cli -p 26379 INFO sentinel
六、生产环境中的最佳实践建议
第一，Sentinel和Redis节点不要部署在同一台机器上，否则机器宕机时监控和被监控的同时消失，毫无意义。第二，至少部署三个Sentinel实例分布在不同物理机或可用区。第三，合理设置quorum值，生产环境建议设为2或3，避免网络抖动导致误判。第四，开启从节点的只读功能分担读压力，但要注意主从切换后读请求需要重新路由。
第五，对于Cluster模式，每个主节点至少配一个从节点，确保故障时有节点可以接管。第六，定期进行故障演练，模拟主节点宕机、网络分区等场景，验证自动转移是否正常工作。第七，客户端要使用支持Sentinel或Cluster的驱动（如Jedis、Lettuce、redis-py等），并配置好重连机制和超时策略。
七、Sentinel与Cluster的选型对比
很多人纠结该用Sentinel还是Cluster。简单来说：数据量小、读多写少、架构简单用Sentinel就够了；数据量大、需要水平扩展、高并发场景必须上Cluster。Sentinel的优势是配置简单、运维成本低、对客户端友好；Cluster的优势是自动分片、线性扩展、无需代理层。在实际生产中，也可以混合使用——用Cluster做数据层，用Sentinel监控每个Cluster节点的健康状态。
还有一个容易被忽略的点：无论Sentinel还是Cluster，都不能保证数据零丢失。Redis的异步复制意味着主节点故障时，最后几秒的写操作可能还没同步到从节点。如果业务对数据一致性要求极高，需要结合AOF持久化策略（建议everysec）和合理的复制配置来最大程度降低数据丢失风险。
八、常见故障排查思路
遇到Redis高可用故障时，按以下顺序排查：首先检查网络连通性，ping和telnet端口是否正常；其次查看Sentinel日志，确认是否有频繁的SDOWN/ODOWN记录；然后检查从节点的复制状态，用INFO replication看master_link_status是否为up；再看是否有内存不足导致的OOM或swap使用；最后确认配置文件中的timeout和quorum参数是否合理。大多数生产故障都是网络抖动或配置不当引起的，真正的硬件故障反而少见。
总结来说，Redis的高可用不是部署完就万事大吉的事情。Sentinel监控要持续运营，故障转移要定期演练，监控告警要覆盖全链路。只有把监控、告警、自动转移、人工预案这四层防线都建好，分布式数据库的可靠性才真正有保障。
