Redis(三)哨兵机制剖析

Redis哨兵机制剖析

1. 什么是高可用

解释1：它与被认为是不间断操作的容错技术有所不同。是目前企业防止核心系统因故障而无法工作的最有效保护手段 
解释2：高可用一般指服务的冗余，一个服务挂了，可以自动切换到另外一个服务上，不影响客户体验。

2. 多种模式对比

1，主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主
2，主从复制主节点的写能力单机，能力有限
3，单机节点的存储能力也有限

3. 主从故障如何故障转移

    A.主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；
    B.其它的节点成为新主节点的从节点，并从新节点复制数据；
    C.需要人工干预，无法实现高可用。

4. 哨兵机制(sentinel)的高可用

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

5、哨兵机制的三个定时监控任务作用

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

6、哨兵主观下线

主观下线

主观下线后，不准确，不会做故障转移

7、哨兵客观下线

客观下线

8、领导者哨兵选举流程

9. 哨兵机制－故障转移流程A

A，由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

10、哨兵机制－故障转移流程B

11、哨兵机制－故障转移流程C

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

12、哨兵机制－故障转移后的拓扑结构图D

13、哨兵机制－故障转移详细流程

14、RedisSentinel如何安装与部署

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

15、安装与部署1（先搭主从）

前提：
先搭建好一主两从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
注意：当主从起来后，主节点可读写，从节点只可读不可写

16、哨兵机制核心配置

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

17、哨兵其它配置

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命令

18、哨兵机制启动

启动sentinel服务:
            ./redis-sentinel conf/sentinel_26379.conf &
            ./redis-sentinel conf/sentinel_26380.conf &
            ./redis-sentinel conf/sentinel_26381.conf &

19、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的错误地址

20、RedisSentinel如何监控2个redis主节点呢？

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

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

21、部署建议

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

22、哨兵的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 //关闭

23、客户端连接（redis-sentinel例子工程）

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