在前面的文章中介绍了Redis的主从复制，但主从复制存在一定的缺陷。如果Master节点宕机，因为不具备自动恢复功能，需要人工干预，那么在这个干预过程中Redis将不可用.

为了解决这一问题，Redis官方推荐一种高可用方案：哨兵模式（Sentinel）.

1、什么是哨兵模式？

哨兵模式是Redis的高可用解决方案之一，它旨在提供自动故障转移和故障检测的功能。在传统的Redis部署中，单个Redis节点可能成为单点故障，一旦该节点宕机，整个系统将不可用。为了解决这个问题，哨兵模式引入了多个Redis节点，其中一个节点被选为主节点，其他节点作为从节点.

2、工作原理

Redis为哨兵模式提供了专属的命令及配置文件，是以独立进程运行，先来看看单哨兵模式:

在上面模式中，哨兵主要有几个作用:

• 监控状态：会向所有监控对象每秒发送ping命令，通过是否有响应来判断master和所有slave节点状态。
• 故障转移：当一旦发现Master节点异常，它将尝试进行故障转移，选择新的slave节点为master节点，并通过发布订阅的方式通知其他slave节点修改配置。

但在上面的模式中，哨兵节点也存在单点故障。因此，为防止Sentinel发生意外，Sentinel也需要实现集群高可用.

上图就构成了多哨兵模式，实现了哨兵节点的高可用.

• Sentinel不只是监控Redis节点，各Sentinel节点之间也会互相监控

3、哨兵模式的特点

哨兵模式具有以下特点:

3.1、自动检测及故障转移

当主节点宕机时，哨兵模式可以自动检测到宕机事件，并从从节点中选举出新的主节点，确保系统的持续可用性.

3.2、主观下线和客观下线

主观下线 是指一个哨兵节点认为主节点不可用，但它并不确定其他哨兵节点是否也认为主节点不可用。当一个哨兵节点在一定时间(配置参数：down-after-milliseconds)内无法与主节点通信（比如发送PING命令没有收到响应），它会认为主节点下线。但在这个阶段，其他哨兵节点并不知道这个节点的状态，仅有一个哨兵主观地认为主节点宕机.

客观下线 是指一个主节点被多数哨兵节点认定为不可用。当一个哨兵节点认为主节点宕机后，它会向其他哨兵节点询问对主节点的状态，并请求其他哨兵进行确认。如果多数（大多数至少需要半数加1）的哨兵节点都认为主节点不可用，那么主节点就会被判定为客观下线。 客观下线意味着主节点的状态在整个哨兵集群中得到了确认.

主观下线和客观下线的引入是为了避免误判。如果只有一个哨兵节点认为主节点下线，那么很可能是网络抖动等原因导致的，此时并不应该进行故障转移。只有多数的哨兵节点都确认主节点下线，才能确保故障转移的正确性，保证整个集群的稳定性.

哨兵模式使用主观下线和客观下线状态的组合来实现可靠的主节点故障检测和故障转移，从而确保Redis集群的高可用性.

3.3、投票选举

在多Sentinel模式下，各节点会相互监控主从节点的健康状态。当主节点发生故障时，首先由Sentinel节点之间基于 Raft 算法进行投票选举，按照谁发现主节点故障谁去处理的原则，选举出一个领头Sentinel节点（Leader Sentinel）。这个领头Sentinel节点负责进行故障转移操作.

故障转移过程中，领头Sentinel节点会根据一定的规则在所有从节点中选择一个最优的从节点作为新的主节点（Master）。一般会选择复制偏移量最大且优先级较高的从节点作为新的主节点。然后，领头Sentinel节点通过发布订阅功能，通知其他从节点更改配置文件，将它们的连接从原来的主节点转移到新的主节点上.

对于客户端来说，连接Redis集群时首先连接到Sentinel节点，通过Sentinel节点查询主节点的地址。一旦主节点发生故障并进行了故障转移，Sentinel节点会将最新的主节点地址告知客户端。这样，客户端无需重启，就可以自动连接到新的主节点，实现高可用性的数据交互.

4、如何使用哨兵模式？

要使用哨兵模式，我们需要在sentinel.conf配置文件中指定Master节点的信息，并启动哨兵进程。当哨兵进程启动后，它会自动发现并监控Redis节点的状态.

以下是一个简单的配置文件示例:

                        
                          sentinel monitor monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 10000

                        
                      

• sentinel monitor <master-name> <ip> <redis-port> <quorum> ：让 sentinel 监控地址为 ip:port 的Master，master-name 可以自定义；<quorum> 表示当有多少个 sentinel 认为主服务器宕机时，它才算真正的宕机掉，通常数量为半数或半数以上数量设置。
• sentinel down-after-milliseconds <master-name> <milliseconds> ：在指定的毫秒数内，若主节点没有应答哨兵的 PING 命令，此时哨兵认为服务器主观下线，默认时间为 30 秒。
• parallel-syncs <master-name> <number> ：指定可以有多少个 Redis 服务同步新的主机，一般而言，这个数字越小同步时间越长，而越大，则对网络资源要求就越高。
• failover-timeout <master-name> <milliseconds> ：指定故障转移允许的毫秒数，若超过这个时间，就认为故障转移执行失败，默认为 3 分钟。

启动命令:

                        
                          ./src/redis-sentinel sentinel.conf

                        
                      

5、 哨兵模式的局限性

虽然哨兵模式提供了一定程度的高可用性，但它仍然有一些局限性:

• 故障转移可能会引起数据丢失。在故障转移期间，可能会丢失尚未同步到从节点的数据.

• 哨兵模式的多维护了一套配置，维护成本相对较高.

6、结论

本文介绍了Redis的哨兵模式，它是一种提供高可用性的解决方案。我们了解了哨兵模式的特点、使用方法以及其局限性。在实际应用中，要根据需求和现有技术栈来选择合适的高可用解决方案.

希望本文对你理解Redis的哨兵模式有所帮助。下一篇文章中，我们将继续探讨Redis的集群。敬请期待！ 。

最后此篇关于Redis从入门到放弃（8）：哨兵模式的文章就讲到这里了,如果你想了解更多关于Redis从入门到放弃（8）：哨兵模式的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。