一、引言
上一篇文章我们详细的讲解了Redis的主从集群模式，其实这个集群模式配置很简单，只需要在Slave的节点上进行配置，Master主节点的配置不需要做任何更改，但是有一点，Master和Slave两个节点的持久化配置尽量保持一致，否则会有奇怪的问题出现。从今天开始我们开始讲Redis集群模式的第二模式，也就是“哨兵”模式，该模式是从Redis的2.6版本开始提供的，但是当时这个版本的模式是不稳定的，直到Redis的2.8版本以后，这个哨兵模式才稳定下来，在生产环境中，如果想要使用Redis的哨兵模式，也会尽量使用Redis的2.8版本之后的版本。无论是主从模式，还是哨兵模式，这两个模式都有一个问题，不能水平扩容，并且这两个模式的高可用特性都会受到Master主节点内存的限制。还有一点，实现哨兵模式的配置也不简单，甚至可以说有些繁琐，所以在工业场景里这两个模式都不建议使用，如果要使用必须有相关的问题的解决方案，以免后续带来的问题。
二、Redis Sentinel简介
Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本。哨兵(Sentinel) 是一个分布式系统，你可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossipprotocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，英文名称：Subjective Down，简称SDOWN。有主观宕机，肯定就有客观宕机。当“哨兵群”中的多数Sentinel进程在对Master主服务器做出 SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，这种方式就是“客观宕机”，英文名称是：Objectively Down， 简称 ODOWN。通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移（failover）。
哨兵(sentinel) 虽然有一个单独的可执行文件 redis-sentinel,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)，哨兵(sentinel) 的一些设计思路和zookeeper非常类似。
Sentinel集群之间会互相通信，沟通交流redis节点的状态，做出相应的判断并进行处理，这里的主观下线状态和客观下线状态是比较重要的状态，它们决定了是否进行故障转移，可以 通过订阅指定的频道信息，当服务器出现故障得时候通知管理员，客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器，你不可以使用 PUBLISH 命令向这个服务器发送信息，但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通过订阅给定的频道来获取相应的事件提醒。一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。
1、Sentinel（哨兵）进程的作用：
1】、监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
2】、提醒(Notification)：当被监控的某个Redis节点出现问题时,哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
3】、自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作，它会将失效Master的其中一个Slave升级为新的Master,并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。
2、Sentinel（哨兵）进程的工作方式：
1】、每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
2】、如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）。
3】、如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。
4】、当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）。
5】、在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
6】、当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
7】、若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。
3、哨兵模式的环境：
1】、Master主服务器配置信息：IP:192.168.127.128,Port:6379，OS:Linux
2】、Slave从服务器的配置信息：IP:192.168.127.129 Port:6379，OS:Linux
3】、在Slave从服务器上安装了一个哨兵进程（Sentinel），在Master服务器也安装了一个哨兵进程（Sentinel）。
由于两个Redis服务器都是安装在Linux操作系统上，而且这两个Redis服务器会在Master主服务器发生故障的时候会进行切换，必须保证两个Redis服务器的端口号已经增加进了防火墙，或者把两个Linux操作系统的防火墙关闭，否则会提示Master-link-Status:down，没有连接上Master主服务器。解决办法有两个：第一个办法是关闭两个Linux操作系统的防火墙；第二个办法是把各个Redis服务的端口号增加到防火墙里面，允许通过该端口号进行通信。可以先使用命令 【firewall-cmd --query-port=6379/tcp】,如果结果是 No，那就继续执行以下命令【firewall-cmd --add-port=6379/tcp】，命令执行后，返回Success，表示增加成功。这样两个Linux系统上的Redis服务器就可以顺利切换，执行哨兵模式的操作。
三、哨兵模式的配置
下面是我使用的配置，需要修改的配置项我写了出来，没有更改的配置项就是用默认值，就不会写出来：
1、###### Master config（redis.conf）
1.1、### NETWORK 设置： bind 192.168.127.128 //绑定IP地址，可以通过ifconfig 获取Ip地址(在Linux系统下) port 6379 保持默认值，也可以修改 timeout 30 Client 端空闲断开连接的时间 1.2、### GENERAL 设置： daemonize yes 默认值是no，把值修改为yes，以后台模式运行 logfile /root/application/program/redis-tool/logs/redis.log 日志文件的位置 1.3、### SNAPSHOTTING 设置： dir /root/application/program/redis-tool/datas SNAPSHOTTING文件的路径 1.4、### APPEND ONLY MODE 设置： appendonly yes 默认值是No，意思是不使用AOF增量持久化的方式，使用RDB全量持久化的方式。把No值改成Yes，使用AOF增量持久化的方式 appendfsync always
2、###### Slave Config（redis.conf）
2.1、### NETWORK 设置： bind 127.129 port 6379 timeout Client 端空闲断开连接的时间 2.2、### GENERAL 设置： daemonize yes logfile /root/application/program/redis/logs/redis.log 日志文件的位置 2.3、### SNAPSHOTTING 设置： dir /root/application/program/redis/datas SNAPSHOTTING文件的路径 2.4、### REPLICATION 设置： slaveof 127.128 主服务器的Ip地址和Port端口号 slave-serve-stale-data no 如果slave 无法与master 同步，设置成slave不可读，方便监控脚本发现问题。 2.5、### APPEND ONLY MODE 设置： appendonly yes appendfsync always
3、###### Sentinel Config（sentinel.conf，192.168.127.129 Slave从服务器）
3.1、 ### Port 设置：
port 26379 哨兵端口号保持不变，可以修改，但是我没有修改
3.2、### dir 设置：
dir /root/application/program/redis/sentinel/ 哨兵程序的日志路径
3.3、### Sentinel Monitor 设置：
sentinel monitor mymaster 127.129 6379 1
3.4、### Down-After-Milliseconds 设置：
sentinel down-after-milliseconds mymaster 5000
哨兵程序每5秒检测一次Master是否正常
3.5、### Parallel-Syncs 设置：
sentinel parallel-syncs mymaster 3.5、### Failover-Timeout 设置：
sentinel failover-timeout mymaster 60000
3.5、### 启动：redis-sentinel
redis-server sentinel.conf --sentinel & (&有这可以Ctrl +C退到命令行，没有这个就直接退出哨兵进程)
redis-sentinel /path/to/sentinel.conf & 对于 redis-sentinel 程序， 你可以用以下命令来启动 Sentinel 系统
3.6、### 关闭：redis-sentinel
pkill redis-server 这个会关掉Redis服务器和Sentinel（哨兵）进程
kill 进程号 可以关掉指定进程号的进程
4、###### 模式测试
4.1、在Sentinel.conf配置文件设置 sentinel monitor：
4.2、在Sentinel.conf配置文件设置 sentinel down-after-milliseconds：
4.3、在Sentinel.conf配置文件设置 sentinel parallel-syncs：
4.4、Master 主服务器的配置详情：
4.5、Slave 从服务器配置详情：
4.6、启动Sentinel（哨兵）进程，开始对Master主服务器进行监控：
4.7、我们人为模仿Master主服务器宕机：
4.8、实现Master主服务器和Slave从服务器的切换：
4.9、主从切换后，主服务器变成了Slave 从服务器，详情如下：
4.10、主从切换后，从服务器变成了Master 主服务器，详情如下：
注意：
① INFO
sentinel的基本状态信息
②SENTINEL masters
列出所有被监视的主服务器，以及这些主服务器的当前状态
③ SENTINEL slaves
列出给定主服务器的所有从服务器，以及这些从服务器的当前状态
④SENTINEL get-master-addr-by-name
返回给定名字的主服务器的 IP 地址和端口号
⑤SENTINEL reset
重置所有名字和给定模式 pattern 相匹配的主服务器。重置操作清除主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel 。
⑥SENTINEL failover
当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移，但是它会给其他sentinel发送一个最新的配置，其他sentinel会根据这个配置进行更新
四、主观下线和客观下线
下面我们来解释一下两个“下线”的概念，一个是“主观下线”，另一个就是“客观下线”。
主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断。（一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内，对向它发送 PING 命令的 Sentinel（哨兵）进程返回一个有效回复（valid reply），那么 Sentinel（哨兵）进程就会将这个服务器标记为主观下线。
服务器对 PING 命令的有效回复可以是以下三种回复的其中一种：
1、返回 +PONG 。
2、返回 -LOADING 错误。
3、返回 -MASTERDOWN 错误。
如果服务器返回除以上三种回复之外的其他回复，又或者在指定时间内没有回复 PING 命令，那么 Sentinel（哨兵）进程认为服务器返回的回复无效（non-valid）。
如果一个服务器在 master-down-after-milliseconds 毫秒内，一直返回无效回复才会被 Sentinel 标记为主观下线。
举个例子，如果 master-down-after-milliseconds 选项的值为 30000 毫秒（30 秒），那么只要服务器能在每 29 秒之内返回至少一次有效回复， 这个服务器就仍然会被认为是处于正常状态的。
从“主观下线”状态切换到“客观下线”状态并没有使用严格的法定人数算法（strong quorum algorithm），而是使用了流言协议，该协议解释为：如果 Sentinel（哨兵）进程在给定的时间范围内，从其他 Sentinel（哨兵）进程那里接收到了足够数量的主服务器下线报告， 那么 Sentinel（哨兵）进程就会将主服务器的状态从“主观下线”改变为“客观下线”。如果之后其他 Sentinel（哨兵）进程不再报告主服务器已下线，那么“客观下线”状态就会被移除。
“客观下线”条件只适用于主服务器：对于任何其他类型的 Redis 实例， Sentinel（哨兵）进程在将它们判断为下线前不需要进行协商，所以Slave从服务器或者其他 Sentinel（哨兵）进程永远不会达到“客观下线”条件。
只要有一个 Sentinel（哨兵）进程发现某个主服务器进入了“客观下线”状态，这个 Sentinel（哨兵）进程就可能会被其他 Sentinel（哨兵）进程推选出，并对失效的主服务器执行自动故障迁移操作。
五、Sentinel（哨兵）配置文件简介
在Redis的源码中包含了一个名为 sentinel.conf 的文件， 这个文件就是带有注释的Sentinel（哨兵）的配置文件的示例。
如果想要运行一个“哨兵”程序，以下配置项是最少配置：
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
第一行配置表示 Sentinel（哨兵）进程去监视一个名为 mymaster 的主服务器，这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379，而将这个主服务器判断为失效至少需要 1 个 Sentinel（哨兵）进程的同意。如果在架构系统中已经配置类多个Sentinel（哨兵）进程，在同意“Master主服务器”下线的 Sentinel（哨兵）进程的数量不达标的情况下，Sentinel（哨兵）进程就不会执行自动故障迁移。在设置多Sentinel（哨兵）进程的情况下，无论设置多少个 Sentinel（哨兵）进程同意才能判断一个服务器失效，一个 Sentinel 都需要获得架构系统中多数 Sentinel（哨兵）进程的支持， 才能发起一次自动故障迁移，并预留一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。如果您只配置了一个Sentinel（哨兵）进程来做监控，那一个Sentinel（哨兵）进程也可以决定“Master主服务器”是否下线。
其他选项的基本格式如下：sentinel <选项的名字> <主服务器的名字> <选项的值>
配置选项的解释如下：
1、down-after-milliseconds ： Sentinel（哨兵）进程判断服务器已经掉线所需的毫秒数。
如果被监控的服务器在给定的毫秒数之内，并没有返回 Sentinel（哨兵）进程发送的 PING 命令的回复，或者返回一个错误，那么 Sentinel（哨兵）进程将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。如果在架构系统中配置了多个Sentinel（哨兵）进程的情况下，只有一个Sentinel（哨兵）进程将服务器标记为主观下线并不一定会引起服务器的自动故障迁移，只有在足够数量的 Sentinel（哨兵）进程都将一个服务器标记为主观下线之后，服务器才会被标记为客观下线（objectively down， 简称 ODOWN ），这时才回执行自动故障迁移。另外一种情况是，在架构系统中只配置了一个Sentinel（哨兵）进程的话，那这Sentinel（哨兵）进程也可以决定被监控的服务器的是否“下线”。
将服务器标记为客观下线所需的 Sentinel（哨兵）进程数量由对主服务器的配置决定。
2、parallel-syncs ：在执行故障转移时，最多可以有多少个从服务器同时对新的主服务器进行同步，这个数字越小，完成故障转移所需的时间就越长。
如果“Slave从服务器”被设置为允许使用过期数据集（参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明），那么你可能不希望所有“Slave从服务器”都在同一时间向新的“Master主服务器”发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞“Slave从服务器”，但“Slave从服务器”在载入“Master主服务器”发来的 RDB 文件时， 仍然会造成“Slave从服务器”在一段时间内不能处理命令请求，如果全部“Slave从服务器”一起对新的“Master主服务器”进行同步， 那么就可能会造成所有“Slave从服务器”在短时间内全部不可用的情况出现。
你可以通过将这个值设为 1 来保证每次只有一个Slave从服务器处于不能处理命令请求的状态。
3、failover-timeout：实现主从切换，完成故障转移的所需要的最大时间值。若Sentinel（哨兵）进程在该配置值内未能完成故障转移的操作（即故障时master/slave自动切换），则认为本次故障转移操作失败。
4、notification-script: 指定Sentinel（哨兵）进程检测到Master-Name所指定的“Master主服务器”的实例异常的时候，所要调用的报警脚本。该配置项可选，但线上系统建议配置。
六、哨兵模式的优缺点
优点：
1、哨兵集群模式是基于主从模式的，所有主从的优点，哨兵模式同样具有。
2、主从可以切换，故障可以转移，系统可用性更好。
3、哨兵模式是主从模式的升级，系统更健壮，可用性更高。
缺点：
1、Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
七、结束
今天就写到这里了，Redis的哨兵模式是以主从模式为基础的，所以说，主从模式拥有的一些缺点，在哨兵模式下也具有。哨兵模式主要是监控Master主服务器的运行情况，当然也会监控Slave从服务器的运行情况，如果Master主服务器发生了故障，该模式可以保证Slave从服务器顺利升级为Master主服务器继续提供服务，以此提高系统的高可用性。虽然哨兵模式比主从模式提高了不少系统的高可用性，但是该模式不能水平扩容，不能动态的增、删节点，这也是限制哨兵模式广泛应用的主要原因。Redis也看到了这个情况，所在在Redis的3.x以后的版本提供了一个更加强大集群模式，那就是Cluster集群模式，这个模式也是我们下一篇文章的主题。