Redis Sentinel

Redis Sentinel

架构

redis sentinel故障转移的步骤

1. 多个sentinel发现却确认master有问题
2. 选举出一个sentinel做为领导
3. 选出一个slave做为master
4. 通知其他的slave成为新的master的slave
5. 通知客户端主从变化
6. 等待老的master复活成为新的master的slave

redis sentinel的安装和配置

在这此前提是你如今当前的集群已经实现了redis的主从复制，要不没法实现如下的功能，若是尚未配置的能够找找我以前写的文章

redis sentinel的配置

mymaster是我所监控的主节点的名字

port ${port}
daemonize yes
dir "XXX"#工做的目录
logfile "${port}.log"#由于有多个sentinel因此习惯性用端口来命令，容易区分日志
sentinel monitor mymaster 127.0.0.1 7000 2#表示有2台sentinel认为这个主节点有问题了，就会开始对它进行下限
sentinel down-after-milliseconds mymaster 30000#sentinel用于检测主节点是否还能连通，能够想象就是ping了以后30000毫秒不通就认为是断开
sentinel parallel-syncs mymaster 1#当主节点发生变化的时候，其他的从节点是如何复制主节点的数据，1是一个个来复制，0是同时进行复制，一个个来会减小主库的压力
sentinel failover-timeout mymaster 1800000#故障转移的时间

在咱们的redis（我使用的是redis-4）中会已经有sentinel的模版，能够在经过这个模版进行一些修改配置

cat sentinel.conf |grep -v '#'|grep -v '^$'#能够去除空格和注释,这样便于修改

修改完成以后能够启动

./redis-sentinel ../config/redis-sentinel-26382.cnf（配置文件目录）#和启动redis-server是同样的

启动完以后，由于sentinel是特殊的redis，能够经过正常的方式启动，例如

redis-cli -p 26382

以后在执行info命令能够看出，sentinel已经知道这个集群的架构，有多少个从库

这是咱们回过头去看，会发现配置已经发生了变化

而后咱们能够按照本身的需求配置多个sentinel，并启动

在我配置的过程当中，由于我是在一台服务器上进行，因此只是端口的差别，这样咱们能够用一些命令去偷懒，哈哈

sed 's/26382/26384/g' redis-sentinel-26382.cnf > redis-sentinel-26384.cnf #这样就能够把redis-sentinel-26382.cnf的26382所有改成26384

具体的命令详情，本身去查询如下哈，由于不是我学习的重点，因此就没写了

我本身在测试的时候，我是启动了三个sentinel，把他们都配置完成并启动以后，执行info命令会发现

他们也互相得感知到了，检测到了当前集群有3个sentinel在管理中

三个定时任务

是为了让每一个sentinel和redis节点保持链接，出现问题后能够准确地快速切换

1.每10秒每一个sentinel对master和slave执行info

• 发现slave节点
• 确认主从关系

2.每2秒每一个sentinel经过master节点的channel交换信息（pub/sub，即发布订阅）

• 经过master的内部频道（_sentinel_:hello）进行交互
• 交互对节点的“见解”和自身的信息
• 当有新的sentinel节点加入进来也会自动地加入该频道和其余的sentinel节点进行通讯

3.每1秒每一个sentinel对其余的sentinel和redis执行ping

• 故障检查
• 心跳检测，失败断定依据

主观下线和客观下线

当监控正在master的sentinel发现master出现问题了，就采起下线操做。
面前咱们有提到两个配置

sentinel monitor mymaster 127.0.0.1 7000 2(quorum)
sentinel down-after-milliseconds mymaster 30000

主观下线：是单个sentinel节点对redis节点失败的“偏见”
客观下线：全部的sentinel节点对redis节点失败“达成共识”（quorum,能够自行根据须要配置）

如何认为master失败呢？
sentinel节点ping超过了第二条配置中设置的时间以后没有回应就认为是失败

当一个sentinel发现了问题，就会向其余的sentinel节点内部会发送sentinel is_master_down_by_addr去“咨询”其余sentinel的意见

领导者选举

在集群中，虽然有多个sentinel进行监控，可是只有一个sentinel节点完成故障转移

1. 当一个节点发现问题以后会向其余的sentinel节点发送sentinel is_master_down_by_addr“咨询”其余sentinel的意见，同时也“发表”了要求将它设置为领导者
2. 收到命令的sentinel节点若是没有赞成经过其余的sentinel节点发送的命令，那么将赞成该请求，不然拒绝
3. 若是该sentinel节点发现本身的票数已经超过sentinel集合半数且超过（quorum），那么它将成为领导者
4. 若是此过程有多个sentinel节点成为了领导者，那么将等待一段时间从新进行选举

故障转移（sentinel 领导者节点完成）

1. 从slave节点中选出一个“合适的”节点做为新的master节点
2. 对上面的slave节点执行slave no one命令让其成为master节点
3. 向剩余的slave节点发送命令，让他们成为新的master节点的slave节点，复制的规则和parallvel_syncs参数有关;sentinel parallel-syncs mymaster 1#当主节点发生变化的时候，其他的从节点是如何复制主节点的数据，1是一个个来复制，0是同时进行复制，一个个来会减小主库的压力`
4. 将更新对原来的master节点配置为slave，并保持对其的“关注”，当其恢复后命令它去复制新的master节点

如何选举“合适的”slave节点

1. 选择slave_priority(slave节点的优先级)最高的slave节点，若是存在即返回，不存在则继续
2. 选择复制偏移量最大的slave节点（复制得最完整），若是存在即返回，不存在则继续
3. 选择runid最小的slave节点