Redis哨兵模式

Redis哨兵比主从复制多了 sentinel 节点，当主节点出现故障的时候，有 sentinel 自动完成故障发现和转移，并通知应用方，实现高可用。

哨兵模式

哨兵如何监控节点？

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

• 每隔10秒，发一次info
• 每隔2秒发一次，publish/subscribe
• 每隔1秒发一次ping（主要靠这种方式）

三个定时监控任务

故障转移

哨兵什么时候可以判断一个节点挂了呢？哨兵也是一个集群，当其中一个哨兵发一个 ping 给 mater 节点，发现在一定时间范围内没有收到 master 的响应，这个哨兵就会认为节点挂了，这个叫做主观下线。一个哨兵是有可能看差匹的，所以主观下线不能确定节点真的已经挂了，还需要其他节点确认。

哨兵主观下线

发现某个节点 ping 不通的哨兵，会通知其它哨兵去检查这个节点是不是真的挂了。如果其他节点也 ping 不通这个节点，那就是哨兵一致认为这个节点挂了，这叫做客观下线。

哨兵客观下线

当 sentinel 集群确认一个 master 节点已经挂了，就会选举一个节点负责故障转移。

sentinel选举

接着被选举为 leader 的 sentinel3 就会执行故障转移，过程就和主从复制一样：

1. slave-1执行：slaveof no one 解除从节点身份，变为新master
2. slave-2 变成新 master 的从节点 slaveof new master
3. 同样，若原主节点恢复，也变成新主节点的从节点
4. 通知应用程序，新主节点的地址

自动完成主从复制流程

整个过程如下所示：

故障转移拓扑图

如何安装与部署 Redis Sentinel

监控一个 redis 主节点

我们以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署。

如何安装与部署redis sentinel

先搭建好主从：

先搭建好一主两从redis的主从复制：
A主节点6379节点（/usr/local/bin/conf/redis6379.conf）：
      修改 requirepass 12345678，注释掉bind 192.168.42.111 
B从节点redis6380.conf和redis6381.conf:
      修改 requirepass 12345678 ,注释掉#bind 192.168.42.111, 
      加上masterauth 12345678 ,加上slaveof 192.168.42.111 6379
注意：当主从起来后，主节点可读写，从节点只可读不可写

哨兵机制核心配置

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 192.168.42.111 6379 2  //监听主节点6379
sentinel auth-pass mymaster 12345678     //连接主节点时的密码
三个配置除端口外，其它一样
配完此脚本，哨兵机制可正常启动运行。

哨兵其它配置

sentinel monitor mymaster 192.168.42.111 6379 2  //监控主节点的IP地址端口
sentinel auth-pass mymaster 12345678  //sentinel连主节点的密码
sentinel config-epoch mymaster 2      //执行故障转移时， 最多可以有多少个从节点同时对新的主节点进行数据同步
sentinel leader-epoch mymaster 2
sentinel failover-timeout mymaster 180000 //故障转移超时时间180s，                            
    a,如果转移超时失败，下次转移时时间为之前的2倍；
    b,从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过180S时，则故障转移失败
    c,从节点复制新主节点时间超过180S转移失败
sentinel down-after-milliseconds mymaster 300000//sentinel节点定期向主节点ping命令

启动sentinel服务:

./redis-sentinel conf/sentinel_26379.conf &
./redis-sentinel conf/sentinel_26380.conf &
./redis-sentinel conf/sentinel_26381.conf &

RedisSentinel节点测试

测试：kill -9 6379  杀掉6379的redis服务
看日志是分配6380 还是6381做为主节点，当6379服务再启动时，已变成从节点

假设6380升级为主节点:
进入6380>info replication     
         role:master
打开sentinel_26379.conf等三个配置，
     sentinel monitor mymaster 192.168.42.111 6380 2 //有2个sentinel认为master下线
打开redis6379.conf等三个配置, slaveof 127.0.0.1 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 主节点

我们以3个Sentinel节点、2个从节点、2个主节点为例进行安装部署

image.png

原配置加上一句：sentinel monitor mymasterB 192.168.1.112 6379 2。

部署建议

a，sentinel节点应部署在多台物理机（线上环境）
b，至少三个且奇数个sentinel节点
c，3个sentinel可同时监控一个主节点或多个主节点，当监听N个主节点较多时，如果sentinel出现异常，会对多个主节点有影响，同时还会造成sentinel节点产生过多的网络连接，一般线上建议还是， 3个sentinel监听一个主节点

哨兵 API

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

  26379> sentinel masters或sentinel master mymaster
  26379> sentinel slaves mymaster 
  26379> sentinel sentinels mymaster //查sentinel节点集合(不包括当前26379)
  26379> sentinel failover mymaster //对主节点强制故障转移，没和其它节点协商

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

客户端连接

远程客户端连接时，要打开protected-mode no
      
在使用工程redis-sentinel，调用jedis查询的流程如下：
     1，将三个sentinel的IP和端口 加入JedisSentinelPool
     2，根据IP和地址创建JedisSentinelPool池对象
     3，在这个对象创建完后，此时该对象已把redis的主节点