所谓的高可用，也叫HA（High Availability），是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。如果在实际生产中，redis只部署一个节点，当机器故障时，整改服务都不能提供服务了。这就是我们常说的单点故障。如果redis部署了多台，当一台或几台故障时，整个系统依然可以对外提供服务，这样就提高了服务的可用性。

Redis的主从架构主要是为了提高并发量，主写从读。那么现在问题来了，现在Master机器挂掉了，其他机器都是Slave，没办法写，我们只能读缓存数据了。等下运维发现机子挂了，赶紧帮忙重启，那这段时间的写请求怎么办？手动解决响应是高延迟的一个操作啊。这么一说，你就会发现这样解决问题很蠢。所以Redis的哨兵机制就是为了解决这个愚蠢的问题。在Redis服务器集群出现问题时及时处理，及时进行故障转移（主备切换），减少系统不能提供服务的时间，这就是哨兵模式要解决的最重要的问题。

哨兵模式是Redis的高可用方式，哨兵节点是特殊的redis服务，不提供读写服务，主要用来监控所有的redis节点。 哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点挂掉时，哨兵会第一时间感知到，并且在slave节点中重新选出来一个新的master，然后将新的master信息通知给client端，从而实现高可用。这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息。

下面将会搭建如下架构的哨兵集群

将 Redis 安装目录中的 sentinel.conf 文件复制到 cluster 目录（该目录是上次搭建伪集群建立的一个目录）中。该配置文件中用于存放一些 sentinel 集群中的一些公共配置。

修改 cluster/sentinel.conf 配置文件。

sentinel monitor 该配置用于指定 Sentinel 要监控的 master 是谁< ip >< redis-port >，并为 master 起了一个名字< master-name >。该名字在后面很多配置中都会使用。同时指定 Sentinel 集群中决定该master“客观下线状态”判断的 sentinel 数量 < quorum >。< quorum >的另一个用途与sentinel 的 Leader 选举有关。要求中至少要有 max(quorum, sentinelNum/2+1)个 sentinel 参与，选举才能进行。

这里将该配置注释掉，因为要在后面的其它配置文件中设置，如果不注释就会出现配置冲突。

sentinel auth-pass 如果 Redis 主从集群中的主机设置了访问密码，那么该属性就需要指定 master 的主机名与访问密码。以方便 sentinel 监控 master。

在 redis 目录下的 cluster 目录中新建 sentinel26380.conf 文件作为 Sentinel 的配置文件，并在其中键入如下内容：

sentinel26380.conf文件保存退出后，在新建sentinel26381.conf和sentinel26382.conf这两个文件，文件内容就是上面的内容，只不过要把所有的26380改为26381和26382即可。最后结果如下：

详见：Redis的主从集群搭建与配置

启动命令 在/usr/local/bin 目录下有一个命令 redis-sentinel 用于启动 Sentinel。不过，我们发现一个奇怪的现象：/usr/local/bin 目录中的 redis-sentinel 命令是 redis-server 命令的软链接。 查看 Redis 安装目录中的 src 目录中的 redis-server 与 redis-sentinel 命令，我们发现这两个命令的大小一模一样。其实，这两个命令本质上是同一个命令。 之所以可以启动不同的进程，主要是因为在启动时所加载的配置文件的不同。所以在启动 Sentinel 时，需要指定 sentinel.conf 配置文件。

两种启动方式

Redis 首先会调用 checkForSentinelMode 函数来判断当前是否以哨兵模式来运行，并把标识赋值到 server.sentinel_mode。

checkForSentinelMode 是如何判断当前是否以哨兵模式来运行：