redis sentinel 哨兵

redis 哨兵

参考链接

##redis中文官网
本文到部分来自中文官网文档

哨兵的作用

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

启动sentinel的两种方式

redis-sentinel redis.conf
redis-server redis.conf --sentinel

原来的主从复制当master假如宕机了，需要我们手动的 slaveof no one 等一些操作切换主从关系
sentinel 可以很好的解决这个问题他会去实时监控master 的情况，当master出现问题，sentinel可以完成故障转换帮我们切换master

sentinel中的概念

主观下线（Subjectively Down，简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
客观下线（Objectively Down，简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断。

什么时候示例被判定为主观下线呢:----如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内，对向它发送 PING 命令的 Sentinel 返回一个有效回复（valid reply），那么 Sentinel 就会将这个服务器标记为主观下线。

故障转移操作:---->只要一个 Sentinel 发现某个主服务器进入了客观下线状态，这个 Sentinel 就可能会被其他 Sentinel 推选出，并对失效的主服务器执行自动故障迁移操作。

每个 Sentinel 都需要定期执行的任务

每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，那么这个实例会被 Sentinel 标记为主观下线。一个有效回复可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
如果一个主服务器被标记为主观下线，那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
如果一个主服务器被标记为主观下线，并且有足够数量的 Sentinel （至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个主服务器被标记为客观下线。
在一般情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。当一个主服务器被 Sentinel 标记为客观下线时， Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
当没有足够数量的 Sentinel 同意主服务器已经下线，主服务器的客观下线状态就会被移除。当主服务器重新向 Sentinel 的 PING 命令返回有效回复时，主服务器的主观下线状态就会被移除。

sentinel 和其他redis实例相互通信·

一个 Sentinel 可以与其他多个 Sentinel 进行连接，各个 Sentinel 之间可以互相检查对方的可用性，并进行信息交换。
Sentinel 可以通过发布与订阅功能来自动发现正在监视相同主服务器的其他 Sentinel ，这一功能是通过向频道 sentinel:hello 发送信息来实现的。
每个 Sentinel 会以每两秒一次的频率，通过发布与订阅功能，向被它监视的所有主服务器和从服务器的 sentinel:hello 频道发送一条信息，信息中包含了 Sentinel 的 IP 地址、端口号和运行 ID （runid）。
每个 Sentinel 都订阅了被它监视的所有主服务器和从服务器的 sentinel:hello 频道，查找之前未出现过的 sentinel （looking for unknown sentinels）。当一个 Sentinel 发现一个新的 Sentinel 时，它会将新的 Sentinel 添加到一个列表中，这个列表保存了 Sentinel 已知的，监视同一个主服务器的所有其他 Sentinel 。
Sentinel 发送的信息中还包括完整的主服务器当前配置（configuration）。如果一个 Sentinel 包含的主服务器配置比另一个 Sentinel 发送的配置要旧，那么这个 Sentinel 会立即升级到新配置上。
在将一个新 Sentinel 添加到监视主服务器的列表上面之前， Sentinel 会先检查列表中是否已经包含了和要添加的 Sentinel 拥有相同运行 ID 或者相同地址（包括 IP 地址和端口号）的 Sentinel ，如果是的话， Sentinel 会先移除列表中已有的那些拥有相同运行 ID 或者相同地址的 Sentinel ，然后再添加新 Sentinel 。

故障转移

一次故障转移操作由以下步骤组成：

发现主服务器已经进入客观下线状态。
对我们的当前纪元进行自增（详情请参考 Raft leader election ），并尝试在这个纪元中当选。
如果当选失败，那么在设定的故障迁移超时时间的两倍之后，重新尝试当选。如果当选成功，那么执行以下步骤。
选出一个从服务器，并将它升级为主服务器。
向被选中的从服务器发送 SLAVEOF NO ONE 命令，让它转变为主服务器。
通过发布与订阅功能，将更新后的配置传播给所有其他 Sentinel ，其他 Sentinel 对它们自己的配置进行更新。
向已下线主服务器的从服务器发送 SLAVEOF 命令，让它们去复制新的主服务器。
当所有从服务器都已经开始复制新的主服务器时，领头 Sentinel 终止这次故障迁移操作。

这时对sentinel也已经有了大致的了解

配置

讲一下配置写3份改一下端口就行，我这里命名为redis-sentinel.conf

# Sentinel节点的端口
port 16379
dir "/root/redis-sentinel/port16379"
logfile "16379.log"
daemonize yes
# 当前Sentinel节点监控 127.0.0.1:6379 这个主节点
# 2代表判断主节点失败至少需要2个Sentinel节点节点同意
# mymaster是主节点的别名
sentinel monitor mymaster 127.0.0.1 6381 2
#选项指定了 Sentinel 认为服务器已经断线所需的毫秒数 60秒。
sentinel down-after-milliseconds mymaster 60000
# parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。
sentinel parallel-syncs mymaster 2
#故障转移超时时间为180000毫秒
sentinel failover-timeout mymaster 180000

以上配置文件 sentinel monitor mymaster 127.0.0.1 6381 2 当一台master出现故障需要转移时至少需要两个sentinel同意
换句话说，在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。

1.配置主从复制(这个我前面已经写过了)

假设现在有4个redis实例 port 分别为 6379 6380 6381 6382
其中 6379为master
我这里已经启动好了4个实例redis

2 开始配置sentinel
我这里准备启动3个 sentinel ，被监控的master下线后需要2个sentinel主观下线，被选举的sentinel才会执行故障转移

启动sentinel
redis-sentinel redis-sentinel.conf
可以看到我这里已经启动起来了
查看一下16379 sentinel实例的配置文件

这里说一下启动sentinel之后出现的配置
sentinel config-epoch mymaster 18 ###确认mymater SDOWN时长
sentinel leader-epoch mymaster 18 ###同时一时间最多18个slave可同时更新配置,建议数字不要太大,以免影响正常对外提供服务
sentinel known-slave mymaster 127.0.0.1 6380 ###已知的slave 地址
sentinel known-slave mymaster 127.0.0.1 6381 ###已知的slave 地址
sentinel known-slave mymaster 127.0.0.1 6382 ###已知的slave 地址
sentinel known-sentinel mymaster 127.0.0.1 16380 be964e6330ee1eaa9a6b5a97417e866448c0ae40 ###已知sentinel的唯一id
sentinel known-sentinel mymaster 127.0.0.1 16381 3e468037d5dda0bbd86adc3e47b29c04f2afe9e6 ###已知sentinel的唯一id
sentinel current-epoch 18 ####当前可同时同步的salve数最大同步阀值
我们看一下主从的信息
现在我们可以看到 port6379 是master，我们手动杀了它，看看sentinel会不会给我们切换master，以及别的slave的 master指向改变了没有