redis系列（6）：哨兵机制

1，为何要讲哨兵机制？

A，咱们学习了 redis 的主从复制，但若是说主节点出现问题不能提供服务， 须要人工从新把从节点设为主节点，还要通知咱们的应用程序更新了主节点的地址，这 种处理方式不是科学的，耗时费事

B，同时主节点的写能力是单机的，能力能限

C，并且主节点是单机的，存储能力也有限

其中 2，3 的问题在后面 redis 集群课会讲，第 1 个问题咱们用哨兵机制来解决

2,主从故障如何故障转移(不知足高可用)：

A，主节点(master)故障，从节点 slave-1 端执行 slaveof no one 后变成新主节点

B，其它的节点成为新主节点的从节点，并重新节点复制数据

3，哨兵机制(sentinel)的高可用：

A，原理：当主节点出现故障时，由 redis sentinel 自动完成故障发现和转移，并 通知应用方，实现高可用性。

 

其实整个过程只须要一个哨兵节点来完成，首先使用 Raft 算法（感兴趣的同窗能够查一下， 其实就是个选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知

哨兵有三个定时监控任务完成对各节点的发现和监控：

任务 1，每一个哨兵节点每 10 秒会向主节点和从节点发送 info 命令获取最拓扑结构图，哨 兵配置时只要配置对主节点的监控便可，经过向主节点发送 info，获取从节点的信息，并当 有新的从节点加入时能够立刻感知到

 

任务 2，每一个哨兵节点每隔 2 秒会向 redis 数据节点的指定频道上发送该哨兵节点对于主 节点的判断以及当前哨兵节点的信息，同时每一个哨兵节点也会订阅该频道，来了解其它哨兵 节点的信息及对主节点的判断，其实就是经过消息 publish 和 subscribe 来完成

任务 3，每隔 1 秒每一个哨兵会向主节点、从节点及其他哨兵节点发送一次 ping 命令作一次 心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

主观下线和客观下线：

主观下线：刚我知道知道哨兵节点每隔 1 秒对主节点和从节点、其它哨兵节点发送 ping 作心跳检测，当这些心跳检测时间超过 down-after-milliseconds 时，哨兵节点则认为该节点 错误或下线，这叫主观下线；这可能会存在错误的判断。

 

客观下线：当主观下线的节点是主节点时，此时该哨兵 3 节点会经过指令 sentinel is-masterdown-by-addr 寻求其它哨兵节点对主节点的判断，当超过 quorum（法定人数）个 数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都赞成 下线操做，也就说是客观下线

 

领导者哨兵选举流程：

a,每一个在线的哨兵节点均可以成为领导者，当它确认（好比哨兵 3）主节点下线时，会 向其它哨兵发 is-master-down-by-addr 命令，征求判断并要求将本身设置为领导者，由领导 者处理故障转移；

b,当其它哨兵收到此命令时，能够赞成或者拒绝它成为领导者；

c,若是哨兵 3 发现本身在选举的票数大于等于 num(sentinels)/2+1 时，将成为领导者， 若是没有超过，继续选举…………

4，故障转移机制

A，由 Sentinel 节点按期监控发现主节点是否出现了故障 sentinel 会向 master 发送心跳 PING 来确认 master 是否存活，若是 master 在“必定 时间范围”内不回应 PONG 或者是回复了一个错误消息，那么这个 sentinel 会主观地(单 方面地)认为这个 master

B，当主节点出现故障，此时 3 个 Sentinel 节点共同选举了 Sentinel3 节点为领导， 负载处理主节点的故障转移,

C，由 Sentinel3 领导者节点执行故障转移，过程和主从复制同样，可是自动执行

D，故障转移后的 redis sentinel 的拓扑结构图

5，哨兵机制－故障转移详细流程

A，过滤掉不健康的（下线或断线），没有回复过哨兵 ping 响应的从节点

B，选择 slave-priority 从节点优先级最高（redis.conf）

C，选择复制偏移量最大，指复制最完整的从节点

5，如何安装和部署 Reids Sentinel? 咱们以 3 个 Sentinel 节点、2 个从节点、1 个主节点为例进行安装部署

 

 

1，前提：先搭好一主两从 redis 的主从复制，和以前复制搭建同样，搭建方式以下：

A 主节点 6379 节点（/usr/local/bin/conf/redis6379.conf）： 修改 requirepass 12345678，注释掉#bind 127.0.0.1

B 从节点 redis6380.conf 和 redis6381.conf: 修改 requirepass 12345678 ,注释掉#bind 127.0.0.1, 加上 masterauth 12345678 ,加上 slaveof 127.0.0.1 6379

注意：当主从起来后，主节点可读写，从节点只可读不可写

2，redis sentinel 哨兵机制核心配置(也是 3 个节点)：

/usr/local/bin/conf/sentinel_26379.conf

/usr/local/bin/conf/sentinel_26380.conf

/usr/local/bin/conf/sentinel_26381.conf

将三个文件的端口改为: 26379 26380 26381

而后：sentinel monitor mymaster 190.168.1.111 6379 2 //监听主节点 6379

sentinel auth-pass mymaster 12345678

//链接主节点时的密码 三个配置除端口外，其它同样。

3，哨兵其它的配置：只要修改每一个 sentinel.conf 的这段配置便可：

sentinel monitor mymaster 192.168.1.10 6379 2

//监控主节点的 IP 地址端口，sentinel 监控的 master 的名字叫作 mymaster

2 表明，当集群中有 2 个 sentinel 认为 master 死了时，才能真正认为该 master 已经不可用了

sentinel auth-pass mymaster 12345678 //sentinel 连主节点的密码

sentinel config-epoch mymaster 2 //故障转移时最多能够有 2 从节点同时对新 主节点进行数据同步

sentinel leader-epoch mymaster 2 sentinel failover-timeout mymasterA 180000 //故障转移超时时间 180s，

a,若是转移超时失败，下次转移时时间为以前的 2 倍；

b,从节点变主节点时，从节点执行 slaveof no one 命令一直失败的话， 当时间超过 180S 时，则故障转移失败

c,从节点复制新主节点时间超过 180S 转移失败

sentinel down-after-milliseconds mymasterA 300000//sentinel 节点按期向主节点 ping 命令，当超过了 300S 时间后没有回复，可能就认定为此主节点出现故障了…… sentinel parallel-syncs mymasterA 1 //故障转移后，1 表明每一个从节点按顺序排队一个一个复 制主节点数据，若是为 3，指 3 个从节点同时并发复制主节点数据，不会影响阻塞，但存在 网络和 IO 开

4，启动 sentinel 服务:

./redis-sentinel conf/sentinel_26379.conf &

./redis-sentinel conf/sentinel_26380.conf &

./redis-sentinel conf/sentinel_26381.conf &

关闭：./redis-cli -h 192.168.42.111 -p 26379 shutdown

5，测试：kill -9 6379 杀掉 6379 的 redis 服务

看日志是分配 6380 仍是 6381 作为主节点，当 6379 服务再启动时，已变成从节点

假设 6380 升级为主节点:进入 6380>info replication 能够看到 role:master

打开 sentinel_26379.conf 等三个配置，sentinel monitor mymaster 127.0.0.1 6380 2

打开 redis6379.conf 等三个配置, slaveof 192.168.42.111 6380,也变成了 6380

注意：生产环境建议让 redis Sentinel 部署到不一样的物理机上。

重 要： sentinel monitor mymaster 192.168.42.111 6379 2 //切 记 将 IP 不 要 写 成 127.0.0.1

否则使用 JedisSentinelPool 取 jedis 链接的时候会变成取 127.0.0.1 6379 的错误地址

注：咱们稍后要启动四个 redis 实例，其中端口为 6379 的 redis 设为 master，其余两个设为 slave 。因此 mymaster 后跟的是 master 的 ip 和端口，最后一个’2’表明只 要有 2 个 sentinel 认为 master 下线，就认为该 master 客观下线，选举产生新的 master。 一般最后一个参数不能多于启动的 sentinel 实例数。

哨兵 sentinel 个数为奇数，选举嘛，奇数哨兵个才能选举成功，通常建议 3

 

6，RedisSentinel 如何监控 2 个 redis 主节点呢？

sentinel monitor mymasterB 192.168.1.20 6379 2 ……与上面同样…………。

 

7，部署建议：

a，sentinel 节点应部署在多台物理机（线上环境）

b，至少三个且奇数个 sentinel 节点

c，经过以上咱们知道，3 个 sentinel 可同时监控一个主节点或多个主节点

监听 N 个主节点较多时，若是 sentinel 出现异常，会对多个主节点有影响，同 时还会形成 sentinel 节点产生过多的网络链接，

通常线上建议仍是， 3 个 sentinel 监听一个主节点

8，sentinel 哨兵的 API

命令：redis-cli -p 26379 //进入哨兵的命令模式，使用 redis-cli 进入

26379>sentinel masters 或 sentinel master mymaster //查看 redis 主节点相关信息

26379>sentinel slaves mymaster //查看从节点状态与相关信息

26379>sentinel sentinels mymaster //查 sentinel 节点集合信息(不包括当前 26379)

26379>sentinel failover mymaster //对主节点强制故障转移，没和其它节点协商

9，客户端链接（redis-sentinel 例子工程）

远程客户端链接时，要打开 protected-mode no

./redis-cli -p 26380 shutdown //关闭

在使用工程 redis-sentinel，调用 jedis 查询的流程以下：

1，将三个 sentinel 的 IP 和地址加入 JedisSentinelPool

2，根据 IP 和地址建立 JedisSentinelPool 池对象

3，在这个对象建立完后，此时该对象已把 redis 的主节点 （ 此 时 sentinel monitor mymaster 必 须 写 成 192.168.42.111 6379 2 ， 不 能 为 127.0.0.1，否则查询出来的主节点的 IP 在客户端就变成了 127.0.0.1，拿不到链接了） 查询出来了，当客户准备发起查询请求时，调用 pool.getResource()借用一个 jedis 对象， 内容包括主节点的 IP 和端口；

4，将获得 jedis 对象后，可执行 jedis.get(“age”)指令了……