面试高频考点——Redis哨兵模式概念、细节、配置及测试

一、哨兵模式的概念

        Reids的主从复制，是通过手动切换主从服务器，人工干预，费时费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式，sentinel是redis高可用的解决方案，它能够后台监控主机是否故障，当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。。Redis从2.8开始正式提供了Sentinel（哨兵）架构来解决这个问题。

        哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

哨兵的作用：

• Master状态检测 ，通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他从服务器，修改配置文件，让它们切换主机。

        然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此我们使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

        假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为服务器不可用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover（故障转移）操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的服务器实现切换主机，这个过程称为客观下线。

二、哨兵模式的细节

1.哨兵工作方式（每个Sentinel实例都执行的定时任务）

1. 每个Sentinel以每秒一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个PING命令。
2. 如果一个实例（instance）距离最后一次有效回复PING命令的时间超过 own-after-milliseconds 选项所指定的值（默认30秒），则这个实例会被Sentinel标记为主观下线。
3. 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。 当有足够数量的Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线。
4. 在一般情况下，每个Sentinel 会以每10秒一次的频率向它已知的所有Master，Slave发送 INFO 命令。
5. 当Master被Sentinel标记为客观下线时，Sentinel 向下线的 Master 的所有Slave发送 INFO命令的频率会从10秒一次改为每秒一次。
6. 若没有足够数量的Sentinel同意Master已经下线，Master的客观下线状态就会被移除。 若 Master重新向Sentinel 的PING命令返回有效回复，Master的主观下线状态就会被移除。

2.sentinel三个定时任务

1. 每10秒每个sentinel会对master和slave执行info命令，这个任务达到两个目的：
   a）发现slave节点
   b）确认主从关系
2. 每2秒每个sentinel通过master节点的channel交换信息（pub/sub）。master节点上有一个发布订阅的频道。sentinel节点通过该频道进行信息交换。
3. 每1秒每个sentinel对其他sentinel和redis节点执行ping操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。

3.心跳机制

进入命令传播阶段候，master与slave间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线

master心跳：

指令：PING
周期：由repl-ping-slave-period决定，默认10秒
作用：判断slave是否在线
查询：INFO replication 获取slave最后一次连接时间间隔，lag项维持在0或1视为正常

slave心跳任务:

指令：REPLCONF ACK {offset}
周期：1秒
作用1：汇报slave自己的复制偏移量，获取最新的数据变更指令
作用2：判断master是否在线

4.主观下线和客观下线

主观下线（SDOWN） 指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。

主观下线就是说如果服务器在down-after-milliseconds给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（SDOWN ）。
sentinel会以每秒一次的频率向所有与其建立了命令连接的实例（master，从服务，其他sentinel）发ping命令，通过判断ping回复是有效回复，还是无效回复来判断实例时候在线（对该sentinel来说是“主观在线”）。
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，如果实例在down-after-milliseconds毫秒内，返回的都是无效回复，那么sentinel回认为该实例已（主观）下线，修改其flags状态为SRI_S_DOWN。如果多个sentinel监视一个服务，有可能存在多个sentinel的down-after-milliseconds配置不同，这个在实际生产中要注意。

客观下线（ ODOWN） 指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断，然后开启failover。
客观下线就是说只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线。

只有当master被认定为客观下线时，才会发生故障迁移。
当sentinel监视的某个服务主观下线后，sentinel会询问其它监视该服务的sentinel，看它们是否也认为该服务主观下线，接收到足够数量（这个值可以配置）的sentinel判断为主观下线，既任务该服务客观下线，并对其做故障转移操作。
客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。

5.Redis Sentinel的主从切换方案

Redis 2.8版开始正式提供名为Sentinel的主从切换方案，通俗的来讲，Sentinel可以用来管理多个Redis服务器实例，可以实现一个功能上实现HA的集群，Sentinel主要负责三个方面的任务：

1. 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
2. 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3. 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器作为新的主服务器的从服务器；。当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

6.sentinel集群注意事项

1. 只有Sentinel 集群中大多数服务器认定master主观下线时master才会被认定为客观下线，才可以进行故障迁移，也就是说，即使不管我们在sentinel monitor中设置的数是多少，就算是满足了该值，只要达不到大多数，就不会发生故障迁移。
2. 官方建议sentinel至少部署三台，且分布在不同机器。这里主要考虑到sentinel的可用性，假如我们只部署了两台sentinel，且quorum设置为1，也可以实现自动故障迁移，但假如其中一台sentinel挂了，就永远不会触发自动故障迁移，因为永远达不到大多数sentinel认定master主观下线了。
3. sentinel monitor配置中的master IP尽量不要写127.0.0.1或localhost，因为客户端，如jedis获取master是根据这个获取的，若这样配置，jedis获取的ip则是127.0.0.1，这样就可能导致程序连接不上master
4. 当sentinel 启动后会自动的修改sentinel.conf文件，如已发现的master的slave信息，和集群中其它sentinel 的信息等,这样即使重启sentinel也能保持原来的状态。注意，当集群服务器调整时，如更换sentinel的机器，或者新配置一个sentinel，请不要直接复制原来运行过得sentinel配置文件，因为其里面自动生成了以上说的那些信息，我们应该复制一个新的配置文件或者把自动生成的信息给删掉。
5. 当发生故障迁移的时候，master的变更记录与slave更换master的修改会自动同步到redis的配置文件，这样即使重启redis也能保持变更后的状态。

7.Slave选举与优先级

当一个sentinel准备好了要进行failover（故障转移），并且收到了其他sentinel的授权，那么就需要选举出一个合适的slave来做为新的master。

slave的选举主要会评估slave的以下几个方面：
1）与master断开连接的次数
2）Slave的优先级
3）数据复制的下标(用来评估slave当前拥有多少master的数据)
4）进程ID

三、哨兵模式配置：

1.哨兵配置文件 sentinel.conf

以下是哨兵模式完整配置。

//sentinel.conf

//启动哨兵进程端口(默认26379)  ,如果有哨兵集群，则需要给每个哨兵配置端口
port 26379

//哨兵进程服务临时文件夹，默认为/tmp，要保证有可写入的权限
dir /tmp

/*
	指定哨兵监控的主节点
	master-name：由自己命名的主节点名字只能由字母A-z、数字0-9、这三个字符".-_"组成。
	quorum：配置哨兵认为主节点客观上失联的个数
	格式：sentinel monitor <master-name> <ip> <redis-port> <quorum>
*/
sentinel monitor mymaster 127.0.0.1 6379 2


/*
	当在Redis实例中开启了requirepass foobared授权密码这样所有连接Redis实例的客户端都要提供密码
	设置哨兵sentinel 连接主从的密码注意必须为主从设置一样的验证密码
	格式：sentinel auth-pass <master-name> <password>
*/
sentinel auth-pass mymaster root

/*
	指定多少毫秒之后主节点没有应答哨兵sentinel此时哨兵主观上认为主节点下线（默认30秒）
	格式：sentinel down-after-milliseconds <master-name> <mi17iseconds>
*/
sentine1 down-after-milliseconds mymaster 30000

/*
	发生failover（故障转移）主备切换时最多可以有多少个slave同时对新的master进行同步
	格式：sentine1 parallel-syncs <master-name> <numslaves>
*/
sentinel parallel-syncs mymaster 1

/*
	指定故障切换允许的毫秒数，超过这个时间，就认为故障切换失败，默认为3分钟
	格式：sentinel failover-timeout <master-name> <milliseconds>
*/
sentinel failover-timeout mymaster 180000

/*
	指定sentinel检测到该监控的redis实例指向的实例异常时，调用的报警脚本。该配置项可选，比较常用
	格式：sentinel notification-script <master-name> <script-path>
*/
sentinel notification-script mymaster /var/redis/notify.sh

/*
	客户端重新配置主节点参数脚本，通知相关的客户端关于master地址已经发生改变的信息
	格式：sentinel client-reconfig-script <master-name> <script-path>
*/ 
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

2.配置文件详解

(1)sentine1 down-after-milliseconds

        指定多少毫秒之后主节点没有应答哨兵sentinel此时哨兵主观上认为主节点下线（默认30秒），当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover，此时哨兵会重写Redis的哨兵配置文件，以适应新场景的需要。

(2)sentinel parallel-syncs

        这个配置项指定了在发生failover（故障转移）主备切换时最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的s1ave因为replication而不可用。可以通过将这个值设为1来保证每次只有一个slave 处于不能处理命令请求的状态。

(3)sentinel failover-timeout

故障转移的超时时间failover-timeout可以用在以下这些方面:

1. 同一个sentinel对同一个master两次failover之间的间隔时间。
2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
3. 当想要取消一个正在进行的failover所需要的时间。
4. 当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了

(4)sentinel notification-script

        配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
对于脚本的运行结果有以下规则;

1. 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
2. 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
3. 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
4. 一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。

        通知型脚本:当sentine1有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等)，将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentine1.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentine1无法正常启动成功。

(5)sentinel client-reconfig-script

        当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
以下参数将会在调用脚本时传给脚本:
<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>

1. 目前state总是"failover",
2. role是“leader”或者"observer”中的一个。
3. 参数 from-ip，from-port，to-ip，to-port是用来和旧的master和新的master(即旧的slave)通信的

这个脚本应该是通用的，能被多次调用，不是针对性的。

四、哨兵模式测试

1.启动哨兵模式

        前面有讲到，哨兵模式是一个独立的进程，所以需要手动开启该进程，找到redis-sentinel可执行文件，使用：
redis-sentinel 配置文件 启动哨兵模式
值得注意的是，如果在启动时master下有salve，则将其显示出来，如上图。

2.关闭主机（制造master宕机情况）

        对主机使用shutdown命令使其关机。

        如果主节点断开了，哨兵模式就会利用算法，计算出下一个主节点，等待几秒后，等到哨兵给主机发送命令，检测到主机异常，便会自动切换分支。

        分析其打印出的日志，可以发现其自动对6382（master）进行了故障转移，让6381（salve）变为了master，使用info replication查看，其确实为主机。

        那么，此时就出现了一个问题。当原来的master重新连接后，它会重新成为master还是降为salve呢？我们接着往下看。

4.重新连接原来的主机

        神奇的一幕发生了，等原本master连接回来之后，其变为了现任master的salve。

五、哨兵模式优缺点

1.优点：

1. 哨兵集群，基于主从复制模式，所有的主从配置优点，它全有。
2. 主从可以切换，故障可以转移，系统的可用性更好
3. 哨兵模式是主从模式的升级，手动到自动，更加健壮

2.缺点：

1. Redis不好在线扩容，若容量达到上限，在线扩容十分麻烦
2. 哨兵模式配置十分麻烦

参考文献：
Redis哨兵模式（sentinel）学习总结及部署记录（主从复制、读写分离、主从切换）