Sentinel哨兵模式（一主二从三哨兵）
结点名称	IP地址	启动端口
master主结点	127.0.0.1	6379
slave从结点1	127.0.0.1	6380
slave从结点2	127.0.0.1	6381
sentinel哨兵结点1	127.0.0.1	26379
sentinel哨兵结点2	127.0.0.1	26380
sentinel哨兵结点3	127.0.0.1	26381

哨兵模式是基于主从模式之上搭建的，所以这里主从模式的环境就不再重复搭建了，如果不会搭建的可以看下这篇文章【主从模式】。

（1）搭建主从模式

首先搭建一个主从模式，参考【Redis主从模式】文章。

（2）创建sentinel配置文件

在Redis的安装目录下，创建三个sentinel配置文件，文件名称分别是：

sentinel26379.conf、sentinel26380.conf、sentinel26381.conf。

配置文件的内容如下所示：

# 启动端口
port 26379
# 禁止保护模式
protected-mode no
# 配置监听的主服务器，这里sentinel monitor代表监控
# master-name代表主结点服务器的名称,可以自定义
# master-ip代表监控的主服务器,master-port代表端口
# quornum代表只有quornum个以上的哨兵认为主服务器不可用的时候,才会进行failover故障转移操作。
# sentinel monitor <master-name> <master-ip> <master-port> <quornum>
sentinel monitor custom-master 127.0.0.1 6379 2
# sentinel auth-pass定义服务的密码，custom-master是服务名称，123456是Redis服务器密码
# sentinel auth-pass <master-name> <password>
# sentinel auth-pass custom-master 123456
# 设置 sentinel 的唯一ID标识,不设置会自动生成一个,不同的sentinel结点的ID不同
sentinel myid 24daf4ea2601497b129141742020b34fd749021c

注意：三个sentinel配置文件除了port端口和myid不同之外，其他的是相同的。

（3）启动sentinel哨兵结点

windows打开CMD命令行窗口，采用【redis-server.exe sentinel26379.conf –sentinel】目录启动sentinel结点。依次启动三个sentinel哨兵服务，如下所示：

（4）查看sentinel结点信息

哨兵结点启动成功之后，可以连接哨兵结点【redis-cli.exe -h 127.0.0.1 -p 26379】，然后通过【info sentinel】命令查看结点信息。

注意：先启动主从模式中的master和slave结点，然后再查看sentinel哨兵结点信息。

（5）模拟故障转移

前面几个步骤已经成功将Sentinel哨兵模式环境搭建好啦，下面就模拟一下master主结点宕机时候，哨兵是否会主动将slave结点提升为新的master主结点。

windows下，通过【Ctrl+C】方式将master主结点服务结束掉。

连接一个sentinel哨兵结点，然后通过【info sentinel】命令查看结点信息。

当重新启动原先那个master结点，可以发现，这个原先的master结点会变成新的master结点的从结点。

1.3、哨兵模式原理

（1）通信机制

sentinel哨兵结点的核心作用：就是监听所有的redis主从结点，当master发生故障时候，选择一个slave结点成为master结点。如何才能够知道某个结点是否发生故障呢？？？

sentinel哨兵结点会每秒钟向所有的redis结点发送一个【ping】命令，如果结点是正常的，那么这个结点就会返回一个【PONG】响应给sentinel结点，哨兵结点接收到PONG响应之后，就知道当前这个结点是正常工作的。

（2）主观下线

当sentinel哨兵结点在规定的时间（默认是30秒）里面，没有接收到某个redis结点返回的PONG响应，那么当前这个sentinel哨兵结点就会认为这个redis结点服务不可用了，就将这个redis结点标记为不可用状态，即：下线状态，这种将redis结点标记为下线状态的方式叫做：主观下线。

主观下线并不会立即将redis结点下线，只是会修改当前sentinel哨兵结点中维护的结点状态，sentinel哨兵结点还需要询问其他的sentinel哨兵结点，才能够最终确定这个redis结点是否真的下线了。

（3）客观下线

单独某个sentinel结点认为某个redis结点下线，这种情况是不太准确的，太主观了，所以当某个sentinel哨兵发现redis结点下线之后，它会向其他的sentinel哨兵结点发送一个命令，用于判断当前这个redis结点是否处于下线状态，其他的sentinel哨兵结点接收到命令之后，会检测redis结点的状态，如果超过半数以上的sentinel哨兵结点都认为这个redis结点是下线状态，那么这个时候就真正的会将这个redis结点标记为下线状态，这种下线方式叫做：客观下线。

（4）选举策略

如果sentinel哨兵结点判断出master主结点处于下线状态了，那么这个时候，哨兵结点之间就会采用某种选举策略，从所有可用的slave从结点中挑出一个slave结点，并将slave结点提升为master结点，通过发送订阅的方式，通知其他的slave从结点，关联到新的master结点上面，最后将原先的master结点修改为slave从结点，这样做的好处是，当原先的master结点重新启动之后，可以正常的加入到主从模式里面。

上面这个操作就是故障转移（默认在3分钟内完成，超过3分钟则认为执行失败），故障转移是由一个sentinel哨兵结点来完成的，如何确定由哪个sentinel哨兵结点进行故障转移呢？？？所有的sentinel哨兵结点会采用某种选举算法，挑选出一个sentinel哨兵结点作为领头结点，这个领头结点就会执行故障转移操作。

到此，Redis中的哨兵模式就介绍完啦。