哨兵模式

Redis Sentinel是Redis官方的高可用性解决方案。
Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance），该系统执行以下三个任务：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作，它会将主从复制组合中的其中一个从服务器升级为新的主服务器，并让其他从服务器指向新的主服务器；当客户端试图连接失效的主服务器时， Sentinel也会向客户端返回新主服务器的地址，使得新主服务器代替失效服务器。

daemonize no该为yes，启动时指定配置文件，redis-server也不会占终端

/usr/bin/redis-server /etc/redis/6379.conf

image.png

Redis Sentinel 是一个分布式系统，你可以在一个架构中运行多个 Sentinel 进程（progress），这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息，并使用投票协议（agreement protocols）来决定是否执行自动故障迁移，以及选择哪个从服务器作为新的主服务器。
虽然 Redis 为 Sentinel 生成一个单独的可执行文件 redis-sentinel ，但实际上它只是一个运行在特殊模式下的 Redis 服务器。
此种模式下，客户端要访问的服务 IP 不是主节点，而是 sentiner 服务器的 IP。

修改/etc/redis-sentinel.conf

bind 0.0.0.0       #绑定ip
protected-mode yes         #能被其他主机识别
daemonize yes                 #可以放到后台运行 

sentinel monitor mymaster master节点IP master节点Port   票数
票数为达到几票就会进行master节点的迁移

sentinel down-after-milliseconds mymaster 3000

sentinel failover-timeout mymaster 180000    # 180 秒后开始故障自动装换

sentinel parallel-syncs mymaster 1

各配置的作用:

down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
如果服务器在给定的毫秒数之内，没有返回 Sentinel 发送的 PING 命令的回复，或者返回一个错误，那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。

不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移：只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后，服务器才会被标记为客观下线（objectively down，简称 ODOWN ），这时自动故障迁移才会执行。

将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。

parallel-syncs 选项指定了在执行故障转移时，最多可以有多少个从服务器同时对新的主服务器进行同步，这个数字越小，完成故障转移所需的时间就越长。

启动哨兵模式

/usr/bin/redis-sentinel /etc/redis-sentinel.conf

redis-cli -p 26379 info sentinel #查看哨兵模式的信息
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=172.17.0.3:6379,slaves=1,sentinels=3

当启动哨兵模式之后,哨兵的配置文件会改变

该实验使用6个容器,3个作为主从,3个作为sentinel,

在容器中使用supervisor管理redis-server和redis-sentinel进程,
supervisorctl stop redis-6379
执行redis-cli -p 26379 info sentinel查看哨兵信息,由于设置了180秒,因此,等待3分钟后,发现哨兵监控的主服务器发生了改变,重新启动down掉的redis,该redis已经成为了从服务器.
测试主从也正常.

sentinel三个定时任务

一套合理的监控机制是Sentinel节点判定节点不可达的重要保证,Redis Sentinel通过三个定时监控任务完成对各个节点发现和监控:

每隔10秒,每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构

image.png

这个定时任务的作用具体可以表现在三个方面:
1.通过向主节点执行info命令,获取从节点的信息,这也是为什么Sentinel节点不需要显式配置监控从节点。
2.当有新的从节点加入时都可以立刻感知出来。
3.节点不可达或者故障转移后,可以通过info命令实时更新节点拓扑信息。

每隔2秒,每个Sentinel节点会向Redis数据节点的sentinel:hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息,同时每个Sentinel节点也会订阅该频道,来了解其他Sentinel节点以及它们对主节点的判断

image.png

每隔1秒,每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测,来确认这些节点当前是否可达。通过上面的定时任务,Sentinel节点对主节点、从节点、其余Sentinel节点都建立起连接,实现了对每个节点的监控,这个定时任务是节点失败判定的重要依据。

image.png

主观下线与客观下线

主观下线

每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测,当这些节点超过down-after-milliseconds没有进行有效回复,Sentinel节点就会对该节点做失败判定,这个行为叫做主观下线。

image.png

客观下线

当Sentinel主观下线的节点是主节点时,该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断,当超过<quorum>个数,Sentinel节点认为主节点确实有问题,这时该Sentinel节点会做出客观下线的决定,这样客观下线的含义是比较明显了,也就是大部分Sentinel节点都对主节点的下线做了同意的判定,那么这个判定就是客观的

image.png

领导者Sentinel节点选举

需要客观下线的节点并不是要所有的sentinel节点来帮助，这个过程仅仅需要一个sentinel节点便可以完成，这时候，就会产生分歧，最后由那个sentinel节点完成呢。这就是选举的必要性，选举过程使用的是Raft算法。Raft算法选举过程的简单讲解：

每个在线的Sentinel节点都有资格成为领导者,当它确认主节点主观下线时候,会向其他Sentinel节点发送sentinel is-master-down-by-addr命令,要求将自己设置为领导者。
收到命令的Sentinel节点,如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令,将同意该请求,否则拒绝。
如果该Sentinel节点发现自己的票数已经大于等于max(quorum,num(sentinels)/2+1),那么它将成为领导者。
如果此过程没有选举出领导者,将进入下一次选举。

image.png

image.png

image.png

故障转移

领导者选举出的Sentinel节点负责故障转移,具体步骤如下:

在从节点列表中选出一个节点作为新的主节点,选择方法如下:

a)过滤:“不健康”(主观下线、断线)、5秒内没有回复过Sentinel节点ping响应、与主节点失联超过 down-after-milliseconds*10秒。
b)选择slave-priority(从节点优先级)最高的从节点列表,如果存在则返回,不存在则继续。
c)选择复制偏移量最大的从节点(复制的最完整),如果存在则返回,不存在则继续。
d)选择runid最小的从节点。

image.png

Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点
Sentinel领导者节点会向剩余的从节点发送命令,让它们成为新主节点的从节点,复制规则和parallel-syncs参数有关。
Sentinel节点集合会将原来的主节点更新为从节点,并保持着对其关注,当其恢复后命令它去复制新的主节点。

redis哨兵模式