redis哨兵机制

一、为什么要使用哨兵机制

redis主从复制存在缺陷，如果主节点出现问题不能提供服务，需要人工重新把从节点设置为主节点，还需要通知应用程序更新了主节点的地址。这样处理是非常不科学的。redis2.8正式提供哨兵架构。

二、哨兵机制原理

当sentinel监控的主节点出现故障时，redis sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。故障转移和通知应用方只需要一个sentinel来完成，这个sentinel是通过Raft算法(选举算法)得到的。

2.1 哨兵机制的三个定时任务

1）每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到。 （所有哨兵节点监控主、从节点）

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

3）每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据。 （所有哨兵会向主、从、其他哨兵节点发送心跳检测节点是否健康）

2.2 主观下线和客观下线

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

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

2.3 领导者哨兵的选举流程

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

2）当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；

3）如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

领导者哨兵的职责是：故障转移以及通知应用方。

2.4主节点故障转移流程

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

2）当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移。将从节点升级为主节点，将其他从节点指向新的主节点。

3）通知客户端主节点已经更换。

4）如果原主节点上线，则设置为从节点。

下图表示步骤2将从节点升级为主节点操作流程图

三、哨兵机制的搭建

3.1主从节点配置（复制三分redis.conf配置文件）

#主节点:6379
bind 127.0.0.1
port 6379
logfile "6379.log"
dbfilename "dump-6379.rdb"
#从节点:6380
bind 127.0.0.1
port 6380
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 127.0.0.1 6379
#从节点:6381
bind 127.0.0.1
port 6381
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 127.0.0.1 6379
#启动主从节点
./src/redis-server 6379.conf &
./src/redis-server 6380.conf &
./src/redis-server 6381.conf &

3.2配置哨兵节点信息（复制三分redis.conf配置文件）

sentinel-26379.conf,sentinel-26380.conf,sentinel-26380.conf这三个配置文件加粗 部分按照实际情况自行设置。

port 26379
daemonize yes  
logfile "26379.log"  
dir /opt/soft/redis/data  
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000  
sentinel parallel-syncs mymaster 1  
sentinel failover-timeout mymaster 180000
sentinel myid mm55d2d712b1f3f312b637f9b546f00cdcedc787
启动哨兵
./src/redis-sentinel sentinel-26379.conf &
./src/redis-sentinel sentinel-26380.conf &
./src/redis-sentinel sentinel-26381.conf &

3.3检查集群信息

通过info replication命令查看集群信息

127.0.0.1:6379> info replication

四、注意事项以及建议

1）sentinel节点建议奇数个（3），这样才能产生领导者哨兵的选举结果

2）建议redis sentinel节点和redis主从节点分开部署到不同的机器。

3） sentinel monitor mymaster 127.0.0.1 6379 2这个一定要将127.0.0.1改成192.168.1.111内网IP地址，否则JedisSentinelPool 取 jedis 连接的时候会变成取 127.0.0.1 6379。

4）sentinel monitor mymaster 192.168.1.111 2中的"2"表示:只要有2个sentinel认为master下线，就认为该master客观下线，选举产生新的master。 （只要2个sentinel同意下线就客观下线master节点）

五、哨兵机制的优缺点

1）解决主从模式下主节点的故障转移工作的。

2）redis中sentinel有效的解决了故障转移的问题，也解决了主节点下线客户端无法识别新的可用节点的问题。

3）但是如果是从节点下线了，sentinel是不会对其进行故障转移的，并且连接从节点的客户端也无法获取到新的可用从节点。