这篇文章，主要介绍Redis运行环境之Sentinel哨兵模式。
目录
一、Sentinel哨兵模式
1.1、哨兵模式原理
上一篇文章介绍了主从模式，主从模式虽然可以提高Redis的读写性能，但是仍然会存在不可用的情况，当master结点出现故障时候，主从模式就没办法正常对外提供服务，这个时候整个项目中和redis写操作的相关功能就没法使用。
为了解决主从模式不可用的问题，我们就需要在master结点出现故障之后，主动的将master结点重新启动，或者选择一个slave结点将其变成新的master结点，这种方式需要人为的干预，才能够让Redis主从模式恢复正常。
有没有什么方式是不需要人为干预，就可以自动的让master主结点重新工作呢？？？这就需要介绍Sentinel哨兵模式，哨兵模式其实就是采用一个应用程序来代替人为干预的这个过程，这个应用程序就叫做：哨兵进程。
哨兵模式大致原理如下所示：
- 首先仍然是主从模式架构，只不过这个时候会引入一个哨兵进程。
- 哨兵进程是单独的redis服务进程，它的主要作用就是：监控所有的master和slave结点的运行状态。
- 当哨兵进程发现master结点出现故障时候，此时会采用某种策略，从所有的slave从结点里面选择一个结点作为新的master结点。
- 然后将其他slave从结点重新连接到新的master结点上面，原先那个master结点会变成新master结点的从结点。
有人可能会问，那如果哨兵进程也发生故障了，那这个主从模式不是一样不可用了吗？？？
- 所以为了保证哨兵进程的高可用，一般情况下，哨兵结点都会设置多个，并且设置成奇数个，例如：3个、5个。
- 一般的模式是：【一主二从三哨兵】。
下面介绍如何搭建哨兵模式。
1.2、哨兵环境搭建
这里采用【一主二从三哨兵】的模式搭建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中的哨兵模式就介绍完啦。
综上，这篇文章结束了，主要介绍Redis运行环境之Sentinel哨兵模式。