redis高可用(二)
redis 哨兵机制
redis 2.8 之后，提供 哨兵(Sentinel) 机制 ，实现 主从节点故障转移。
工作原理：监听主节点是否存活，当主节点挂掉，选举从节点担任新的主节点
工作机制
哨兵节点主要负责三件事情：监控、选主、通知。
- 哨兵节点如何监控节点？如何判断节点是否故障
- 根据什么规则选择从节点切换为主节点
- 怎么把新主节点的相关信息通知给从节点和客户端
如何判断主节点挂了
哨兵会默认每隔 1 秒给所有节点发送一个 PING 命令，如果没有再规定时间内响应，会标记为 「主观下线」， 这个「规定时间」配置项 down-after-milliseconds 单位毫秒
主观下线？客观下线？
之所以设计「主观下线」和「客观下线」是因为主节点压力较大，就没能及时响应 PING 命令
为了减少误判，哨兵在部署时也会部署成 哨兵集群( 至少三台机器 )，通过多个哨兵节点一起判断，就可以避免单个哨兵因为自身网络状况不好，而误判主节点下线的情况
如何判定主节点为「客观下线」？
当一个哨兵判断主节点为「主观下线」后，会向其他哨兵发起命令，会根据自身和主节点的网络状况，做出赞成投票或拒绝投票
当赞成票达到配置文件中 quorum 值后，主节点就会标记为「客观下线」
PS： quorum 值一般为哨兵个数的一半 + 1，(1/2 + 1)
由哪个哨兵进行主从故障转移
哨兵集群中需要一个 Leader ，让 Leader 来执行主从切换
选举 leader 哨兵的过程是一个投票过程，在投票开始前，有一个「候选者」
候选者是谁？
哪个哨兵节点判断主节点为「客观下线」，这个哨兵节点就是候选 Leader
候选者如何选举成 Leader?
候选者向其他哨兵发送命令，表明希望成为 Leader 来执行主从切换，并让所有其他哨兵对它进行投票
任何一个「候选者」，成为 Leader 要满足两个条件：
- 第一，拿到半数以上的赞成票
- 第二，拿到的票数同时还需要大于等于(>=)哨兵配置文件中的 quorum 值
如果某个时间点，有多个哨兵节点判断到主节点为「客观下线」，那么候选者会投自己，其余哨兵节点会投给 先收到「候选者」的投票请求
主从故障转移的过程
主从故障转移操作包含以下四个步骤
- 第一步，在已下线主节点(旧主节点)中所有「从节点」里，选一个转换为主节点
- 第二步，让已下线主节点属下的所有「从节点」修改复制目标，修改为复制「新主节点」
- 第三步，将新主节点的 IP 地址和信息，同步 「发布者/订阅者机制」通知给客户端
- 第四步，继续监视旧主节点，当这个旧主节点上线时，将它设置为主节点的从节点
1.选出新主节点
挑选出一个状态良好、数据完整的从节点为「新主节点」并发送 SLAVEOF no one 命令，将这个「从节点」转换为「主节点」
筛选过滤方式：
- 首先通过网络连接状态过滤，redis中有个
down-after-milliseconds * 10，是主从节点断连的最大连接超时时间，如果超过这个时间，并且发生断连的次数超过 10 次，那么就认为这个节点网络不好，就过滤掉
之后就进行比较 优先级、复制进度、ID 号
- 第一轮考察，根据从节点的优先级进行排序，优先级越小排名越靠前
- 二，如果优先级相同，则查看复制的下标，哪个从「主节点」接收的复制数据多，哪个就靠前。
- 三，如果优先级和下标都相同，就选择从节点 ID 较小的那个
优先级： slave-priority 配置项，可以给从节点设置优先级
复制进度：用 offset进行比较
ID 号小的从节点胜出：比较两个节点 ID
总结
2.将从节点指向新主节点
让已下线主节点属下「从节点」指向「新主节点」，这一动作可以通过向「从节点」
发送 SLAVEOF 命令实现
3.通知客户
通过 发布者/订阅者机制实现通知客户端
主从切换完成后，哨兵向 +switch-master 频道发布新主节点的 IP 地址和端口的消息，这个时候客户端就可以收到这条信息，然后用这里的新主节点的 IP 地址和端口进行通信
4.监视旧主节点
继续监视旧主节点，当就主节点上线后，哨兵集群发送 SLAVEOF 命令，成为新主节点的从节点
哨兵集群
搭建哨兵集群只需要配置几个参数
1 | 设置主节点、主节点的 IP 地址和端口号以及 quorum 值 |
哨兵节点之间通过 Redis 的发布者/订阅者机制来相互发现
主节点上有一个名为 __sentinel__:hello 的频道，不同哨兵通过它来相互发现，订阅其频道，然后发送自己的 IP 地址和端口实现相互发现建立连接
哨兵如何监控从节点信息
哨兵会每 10 秒一次的频率向主节点发送 INFO 命令获取所有「从节点」的信息，并与从节点建立连接