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节点