回顾
上一篇介绍了Redis的主从集群模式，这个集群模式配置很简单，只需要在Slave的节点上进行配置，Master主节点的配置不需要做任何更改。但是，我们发现这种集群模式当主节点宕机，主从无法自动切换，故障无法第一时间转移，需要手工切换主从关系。“哨兵”模式作为Redis集群模式的第二种模式，恰好解决了这个痛点。当Master主服务器发生了故障，哨兵模式可以保证Slave自动顺利的升级为Master主服务器继续提供服务，以此提高系统的高可用性。哨兵模式是从Redis的2.6版本开始提供的，但是当时这个版本的模式是不稳定的，直到Redis的2.8版本以后，这个哨兵模式才稳定下来，在生产环境中，如果想要使用Redis的哨兵模式，要尽量使用Redis2.8版本之后的版本。无论是主从模式，还是哨兵模式，这两个模式都有一个问题，不能水平扩容，并且这两个模式的高可用特性都会受到Master主节点内存的限制。还有一点，实现哨兵模式的配置有些繁琐，所以在生产环境这两个模式都不建议使用，如果要使用必须有相关的问题的解决方案，以免后续带来的问题。
哨兵集群模式（Redis Sentinel）
Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用。哨兵(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）状态的事件。
Sentinel（哨兵）进程的作用
- 监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
- 提醒(Notification)：当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
- 自动故障迁移(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的监控目标会随之调换。
Sentinel（哨兵）进程的工作方式
- 每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
- 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）。
- 如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。
- 当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）。
- 在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
- 当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
- 若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。
具体配置(测试模拟)：
1、还是采用上一篇的两个redis节点测试，1个Master节点(7000)，1个Slaver节点(7001),两个Redis配置文件redis.conf如下：
通过info Replication查看两个角色信息
2、给7001的Slave从节点配置哨兵，sentinel-7001.conf的主要配置项如下：
sentinel哨兵监听端口，默认是26379，可以修改，因为这是从节点（7001）的哨兵，改为27001
port 27001
sentinel monitor <master-name> <ip> <redis-port> <quorum>
告诉sentinel去监听地址为ip:port的一个master，这里的master-name可以自定义，quorum是一个数字，指明当有多少个sentinel认为一个master失效时，master才算真正失效。这里去监听本机的主节点7000端口，将这个主服务器判断为失效至少需要 1 个 Sentinel（哨兵）进程的同意。
sentinel monitor mymaster 127.0.0.1 7000 1
down-after-milliseconds ：Sentinel（哨兵）进程判断主节点已经掉线所需的时间。即需要多少失效时间，一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒，默认为30秒
sentinel down-after-milliseconds mymaster 30000
parallel-syncs ：在执行故障转移时，最多可以有多少个从服务器同时对新的主服务器进行同步，这个数字越小，完成故障转移所需的时间就越长。但是如果这个数字越大，就意味着越多的slave因为数据复制而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
说明：如果“Slave从服务器”被设置为允许使用过期数据集（参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明），那么你可能不希望所有“Slave从服务器”都在同一时间向新的“Master主服务器”发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞“Slave从服务器”，但“Slave从服务器”在载入“Master主服务器”发来的 RDB 文件时， 仍然会造成“Slave从服务器”在一段时间内不能处理命令请求，如果全部“Slave从服务器”一起对新的“Master主服务器”进行同步， 那么就可能会造成所有“Slave从服务器”在短时间内全部不可用的情况出现。
sentinel parallel-syncs mymaster 1
failover-timeout：实现主从切换，完成故障转移的所需要的最大时间值。若Sentinel（哨兵）进程在该配置值内未能完成故障转移的操作（即故障时master/slave自动切换），则认为本次故障转移操作失败。
sentinel failover-timeout mymaster 180000
和redis-server一样，redis-sentinel默认也没有日志文件，可以加上logfile，方便跟踪。
logfile "/var/log/redis/sentinel-27001.log"
还有一个配置：
notification-script: 指定Sentinel（哨兵）进程检测到Master-Name所指定的“Master主服务器”的实例异常的时候，所要调用的报警脚本。该配置项可选，测试的话这里没有配置，但线上系统建议配置。
3、启动7001的Slave节点的哨兵进程
./redis-sentinel ../etc/sentinel-7001.conf & #挂起后台运行
可见，从节点的哨兵进程已启动，监控本机的7000端口主节点，而自己的端口是27001
哨兵进程的日志sentinel-27001.log：显示已监控本机的7000端口的主节点
4、人为模仿Master主服务器宕机
手动kill主节点后，大约过了几十秒（这个时间来自down-after-milliseconds 设定），哨兵进程的日志sentinel-27001.log显示：
这时7000还没有重启，使用info Replication查看7001的角色：
我们手动重启7000，使用info Replication查看7000和7001的角色：
可见，由于哨兵进程的监控，主从关系已自动切换。
我们看下几个配置文件的修改日期，发现在主从自动切换的时间点15:59，配置文件也被改了
而sentinel-7001.conf中最重要的配置被自动改了，哨兵进程正在监控当下的主节点的7001端口：
sentinel monitor mymaster 127.0.0.1 7001 1
两个“下线”的概念
主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内，对向它发送 PING 命令的 Sentinel（哨兵）进程返回一个有效回复（valid reply），那么 Sentinel（哨兵）进程就会将这个服务器标记为主观下线。
服务器对 PING 命令的有效回复可以是以下三种回复的其中一种：
- 返回 +PONG 。
- 返回 -LOADING 错误。
- 返回 -MASTERDOWN 错误。
如果服务器返回除以上三种回复之外的其他回复，又或者在指定时间内没有回复 PING 命令，那么 Sentinel（哨兵）进程认为服务器返回的回复无效（non-valid）。
如果一个服务器在 master-down-after-milliseconds 毫秒内，一直返回无效回复才会被 Sentinel 标记为主观下线。
举个例子，如果 master-down-after-milliseconds 选项的值为 30000 毫秒（30 秒），那么只要服务器能在每 29 秒之内返回至少一次有效回复， 这个服务器就仍然会被认为是处于正常状态的。
客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断。（一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线）
从“主观下线”状态切换到“客观下线”状态并没有使用严格的法定人数算法（strong quorum algorithm），而是使用了流言协议，该协议解释为：如果 Sentinel（哨兵）进程在给定的时间范围内，从其他 Sentinel（哨兵）进程那里接收到了足够数量的主服务器下线报告， 那么 Sentinel（哨兵）进程就会将主服务器的状态从“主观下线”改变为“客观下线”。如果之后其他 Sentinel（哨兵）进程不再报告主服务器已下线，那么“客观下线”状态就会被移除。
“客观下线”条件只适用于主服务器：对于任何其他类型的 Redis 实例， Sentinel（哨兵）进程在将它们判断为下线前不需要进行协商，所以Slave从服务器或者其他 Sentinel（哨兵）进程永远不会达到“客观下线”条件。
只要有一个 Sentinel（哨兵）进程发现某个主服务器进入了“客观下线”状态，这个 Sentinel（哨兵）进程就可能会被其他 Sentinel（哨兵）进程推选出，并对失效的主服务器执行自动故障迁移操作。
哨兵模式的优缺点
哨兵集群模式是基于主从模式的，是主从模式的升级版，所有主从模式的优点，哨兵模式同样具有。
哨兵模式相比于主从模式，主从关系可以自动切换，故障可以自从转移，系统可用性更好。
虽然哨兵模式比主从模式提高了不少系统的高可用性，但哨兵模式归根是来源于主从模式，所以也继承了主从模式的缺点：该模式不能水平扩容，不能动态的增、删节点，高可用性会受到Master主节点内存的限制，这些也是限制哨兵模式广泛应用的主要原因。
Redis也看到了这个情况，所在在Redis的3.x以后的版本提供了一个更加强大集群模式，那就是Cluster集群模式（见下一篇）。