【redis】redis的哨兵

1.redis的哨兵机制

1.主从复制的问题 
一旦主节点出现故障，需要手动将一个从节点晋升为主节点，同事需要修改应用
方的主节点，还需要命令其他从节点去复制新的主节点，这个过程都需要人工干预。
主节点的写能力受到单机的限制。
主节点的存储能力受到单机的限制。

将独立的从节点提升为主节点:
slaveof no one; 

2.redis sentinel高可用 
当主节点出现故障时，redis sentinel 能自动完整故障发现和故障转移，并通知
应用方，从而实现真正的高可用。

redis sentinel 是一个分布式架构，其中包含若干个sentinel节点和redis数据节点，
每个sentinel节点会对数据节点和其余sentinel节点进行监控，当它发现节点不可达时，
会对节点做下线处理。如果被标识的节点是主节点，它还会和其他sentinel节点进行
协调，当大多数sentinel节点都认为主节点不可达时，它们会选举出一个sentinel节点
来完成自动故障转移。同时会将这个变化实时通知给应用方。
redis sentinel与redis主从复制模式只是多了若干sentinel节点，所以redis sentinel 
并没有针对redis节点做了特殊处理。
从逻辑架构上看，sentinel节点集合会定期对所有节点进行监控，特别是对主节点
的故障实现自动转移。

3.故障转移处理的四个流程 
(1)主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败。
(2)每个sentinel节点通过定期监控发现主节点出现了故障。
(3)多个sentinel节点对主节点的故障达成一致，选举出 sentinel-3节点作为领导者负责故障转移。
(4)sentinel领导者节点执行了故障转移。

redis sentinel的功能:
监控:sentinel节点会定期检测redis数据节点，其余sentinel节点是否可达。
通知:sentinel节点会将故障转移的结果通知给应用方。
主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系。
配置提供者:在redis sentinel结构中，客户端在初始化的时候连接的是sentinel
节点集合，从中获取主节点信息。

4.安装和部署sentinel  
(1)启动主节点 
redis-6379.conf  
port 6379 
daemonize yes 
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/opt/soft/redis/data"


redis-server redis-6379.conf 
redis-cli -h 127.0.0.1 -p 6379  ping  
(2)启动两个从节点节点
redis-6380.conf  
port 6380 
daemonize yes 
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/opt/soft/redis/data"
slaveof 127.0.0.1 6379 

redis-6381.conf  
port 6381 
daemonize yes 
logfile "6381.log"
dbfilename "dump-6381.rdb"
dir "/opt/soft/redis/data"
slaveof 127.0.0.1 6379 

redis-server redis-6381.conf
redis-server redis-6380.conf

redis-cli -h 127.0.0.1 -p 6380  ping 
redis-cli -h 127.0.0.1 -p 6381  ping 

(3)确认主从关系 
redis-cli -h 127.0.0.1 -p 6379 info replication 
redis-cli -h 127.0.0.1 -p 6380 info replication 

(4)配置sentinel节点 
vi redis-sentinel-26379.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 

vi redis-sentinel-26380.conf 
port 26380 
daemonize yes  
logfile "26380.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 

vi redis-sentinel-26381.conf 
port 26381 
daemonize yes  
logfile "26381.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 monitor mymaster 127.0.0.1 6379 2
2 代表判断主节点失败至少需要2个sentinel节点同意。
mymaster是主节点的别名。

启动sentinel节点:
redis-sentinel redis-sentinel-26379.conf 
或者:
redis-server redis-sentinel-26379.conf --sentinel 

--检查
sentinel节点本质上是一个特殊的redis节点。
redis-cli -h 127.0.0.1 -p 26379  info sentinel 

生产注意事项:
生产环境中建议redis sentinel的所有节点应该分布在不同的物理机上
redis sentinel中数据节点和普通的redis数据节点在配置上没有区别。
只不过是添加了一些sentinel节点对他们进行监控。

sentinel节点参数说明:
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 monitor:
监控的主节点和故障转移时需要的票数。
sentinel down-after-milliseconds:每个sentinel节点都要通过定期发送ping命令 
来判断redis数据节点和其余sentinel节点是否可达，如果超过了down-after-milliseconds
配置的时间且没有有效的回复，则判定节点不可达。
sentinel parallel-syncs :用来限制在一次故障转移后，每次向新的主节点发起复制
操作的从节点个数。
sentinel failover-timeout:通常被解释为故障转移的超时时间。

sentinel auth-pass mymaster pw123456 
如果sentinel监控的主节点配置了密码，sentinel auth-pass 配置通过添加主节点
的密码，防止sentinel节点对主节点无法监控。
sentinel notification-script 的作用是在故障转移期间，当一些告警级别的
sentinel事件发生时，会触发对应路径的脚本，并向脚本发送相应的事件参数。

5.sentinel set 命令支持的参数 
quorum:sentinel set mymaster quorum 2  
down-after-milliseconds: 	sentinel set mymaster down-after-milliseconds 30000 
failover-timeout: 			sentinel set mymaster failover-timeout 360000
parallel-syncs: 			sentinel set mymaster parallel-syncs 2 
notification-script: 		sentinel set mymaster notification-script /opt/xxx.sh  
client-reconfig-script: 	sentinel set mymaster client-reconfig-script /opt/yy.sh 
auth-pass: 					sentinel set mymaster auth-pass pw123456

注意事项:
sentinel set命令只对当前sentinel节点有效。
sentinel set命令如果执行成功会立即刷新配置文件，这点和redis普通数据节点设置需要执行 
config rewrite 刷新到配置文件不同。
建议所有sentinel系欸但那的配置尽可能一致，这样在故障发现和转移时比较容易达成一致。
sentinel对外不支持config命令。

6.sentinel的常用API;
--查看被监控的主节点的状态
127.0.0.1:26379> sentinel masters 
--展示一个主节点的状态及统计信息。
127.0.0.1:26379> sentinel master mymaster-1 
--展示从节点的状态及统计信息
127.0.0.1:26379> sentinel slaves mymaster-1 
--展示sentinel节点集合
127.0.0.1:26379> sentinel sentinels mymaster-1 
--返回指定集群对应的主节点的IP和PORT;
127.0.0.1:26379> sentinel get-master-addr-by-name mymaster-1 
--清除主节点的相关状态，重写发现从节点和sentinel节点。
127.0.0.1:26379> sentinel reset mymaster-1 
--对指定主节点进行强制故障转移。
127.0.0.1:26379> sentinel failover mymaster-1 
--检测当前可达的sentinel节点数是否达到 quorum 个数。
127.0.0.1:26379> sentinel ckquorum mymaster-1 
--将sentinel节点的配置强制刷到磁盘上，当配置文件损害或者丢失时很有用。
127.0.0.1:26379> sentinel flushconfig 
--取消当前sentinel节点对于指定主节点的监控。
127.0.0.1:26379> sentinel remove mymaster-1
--添加对主节点的监控 
127.0.0.1:26379> sentinel monitor mymaster-1 127.0.0.1 6379 2 

7.redis sentinel的实现原理 
redis sentinel的三个定时任务，主观下线和客观下线，sentinel领导者选举，故障转移。
三个定时任务:
redis sentinel通过三个定时任务完成对各个节点的发现和监控。
(1)每隔10s，每个sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。
	这个定时任务的作用:
	通过向主节点执行info命令，获取从节点的信息。
	当有新的从节点加入时可以立即感知出来。
	节点不可达或者故障转移后，可以通过info命令实时更新节点拓扑信息。
(2)每隔2s,每个sentinel节点会向redis数据节点的 __sentinel__:hello 频道上发送该
sentinel节点对于主节点的判断以及当前sentinel节点的信息。同时每个sentinel节点 
也会订阅该频道，来了解其他sentinel节点以及他们对主节点的判断。这个定时任务完成
两个工作:
	发现新的sentinel节点
	sentinel节点之间交换主节点的状态。
	
(3)每隔1s,每个sentinel节点会向主节点，从节点，其余sentinel节点	
发送一条ping命令做一次心跳检测，来确认这些节点是否可达。

8.主观下线和客观下线 
(1)主观下线 
每个sentinel节点会每隔1s对主节点，从节点，其他sentinel节点发送ping命令做
心跳检测，当这些节点超过down-after-milliseconds进行有效回复，sentinel就会
对该节点做失败判定，这个行为叫做主观下线。
(2)客观下线 
当 sentinel主观下线的节点是主节点时，该sentinel节点会通过 sentinel is-master-down-by-addr 
命令向其他sentinel节点询问对主节点的判断，当超过 quorum 个数，sentinel节点认为 
主节点确实有问题。这时该sentinel节点会做出客观下线的决定。

9.故障转移的步骤 
(1)在从节点列表中选举一个节点作为新的主节点。
	a.过滤"不健康"，5s内没有回复过sentinel节点ping 响应，与主节点失联超过
	down-after-milliseconds*10s。
	b.选择slave-priority 最高的从节点列表，如果存在则返回，不存在则继续。
	c.选择复制偏移量最大的从节点，如果存在则返回，不存在则继续。
	d.选择runid最小的从节点。
(2)sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。
(3)sentinel领导者节点会向剩余的从节点发送命令，让他们成为新的主节点的从节点，
复制规则和 parallel-syncs 参数有关。
(4)sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复 
后命令它去复制新的主节点。

10.节点运维 
(1)节点下线 
临时下线:暂时将节点关掉，之后还会重新启动，继续提供服务。
永久下线:将节点关掉后不再使用，需要做一些清理工作，如删除配置文件，持久化文件，日志文件。

节点下线的原因:
节点所在的机器出现了不稳定或者即将过保被回收 
节点所在机器性能比较差或者内存比较小，无法支撑应用方的需求。
节点自身出现服务不正常情况，需要快速处理。

(2)主节点下线
如果需要手工对主节点进行下线，可以使用 sentinel failover 功能将从节点晋升为主节点。
sentinel failover master-1 
如果想要将指定从节点晋升为主节点，可以将其他从节点的slavepriority配置为0,但是需要
注意 failover 后，将slave-priority调回原值。
	
(3)从节点和sentinel节点下线。
如果需要对从节点或者sentinel节点进行下线，只需要确定好时临时还是永久下线后执行 
相应操作即可。如果使用了读写分离，下线从节点需要保证应用方可以感知从节点的下线
变化，从而把读取请求路由到其他节点。

(4)节点上线 
添加从节点的场景:
使用了读写分离，但现有的从节点无法支撑应用方的流量。
主系欸但没有可用的从节点，无法支持故障转移。
添加一个更强悍的从节点利用手动failover替换主节点。

添加sentinel节点的场景:
当前sentinel节点数量不够，无法达到redis sentinel健壮性要求或者无法达到票数。
原sentinel节点所在机器需要下线。

节点配置需要注意的地方:
sentinel节点配置尽可能一致，这样在判断节点故障时会更加准确。
sentinel节点支持的命令非常有限，例如 config命令是不支持的，而sentinel
节点也需要dir,loglevel 之类的配置.

(5)sentinel节点支持的命令如下:
ping  
sentinel
subscribe 
unsubscribe 
psubscribe 
punsubscribe 
publish 
info 
role 
client 
shutdown