Redis哨兵机制

Redis哨兵的概念

Redis的主从复制模式下，一旦主节点由于故障不能提供服务，需要人工进行主从切换，同时大量的客户端需要被通知切换到新的主节点上，对于有一定规模的应用来说，这种方案是无法接受的。

所以redis就引入了“哨兵来解决这个问题”。

注意：redis哨兵主要是用来解决高可用的问题的！！！

人工恢复主节点故障

上述说的主节点故障之后，可以进行人工工作来处理的。

• 程序员通过监控系统，发现redis主节点故障宕机。
• 程序员从所有节点中，选择一个执行slave no one 使其作为新的主节点。
• 程序员让剩余从节点执行slave of命令从新竹街店开始数据同步。
• 让客户端能够连接新的主节点，完成修改数据的操作。
• 如果原来主节点恢复，执行slave of 使其成为一个新的从节点。

上述操作，不说很繁琐，但作为程序员来说是很烦人的，所以就可以考虑用哨兵自动恢复主节点故障。

哨兵自动恢复主节点故障

 

• 这三个sentinel都是单独的redis sentinel进程，并且这三个哨兵会监控(这些进程之间会建立tcp长连接，通过这样的长连接，定期发送心跳包)现有的redis master跟slave。 

1. 如果是主节点挂了，哨兵就会发挥作用，此时一个哨兵节点发现主节点挂了，还不够，需要多个哨兵节点共同认同这件事情，防止发生误判。
2. 确定主节点真的挂了，这些哨兵节点就会推举出一个leader，由这个leader负责从现有的从节点中挑选出一个作为新的主节点。
3. 挑选出新的主节点之后，哨兵节点就会自动控制被选中的节点执行slave of no one，并且控制其他从节点修改slave of道新的主节点上。
4. 哨兵节点会自动通知客户端程序，告知新的主节点是谁，并且后续客户端在进行写操作，就会针对新的主节点进行操作了。

Redis Sentinel的功能

• 监控：sentinel节点会定期检测redis数据节点、其余哨兵节点是否可达。
• 故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。
• 通知：sentinel节点会将故障转移的结果通知给应用方。

哨兵从新选取主节点的流程

前面提到，主节点确定挂了之后，会推举出一个leader，leader选出一个新的主节点，下面就介绍一下选取主节点的流程。

1.主观下线

哨兵节点通过心跳包，判定redis服务器是否正常工作，如果心跳包没有如期而至，就说明rdis服务器挂了，因为还不能排除网络波动的影响，因此就只能是单方面认为这个redis节点挂了。

2.客观上线

多个哨兵都认为主节点挂了（认为挂了的哨兵节点树木达到法定票数），哨兵们就认为这个节点是客观下线。

此处的2就是法定票数。

3.选举出哨兵的leader

哨兵把剩余的从节点中挑选出一个新的主节点，这个工作不需要所有哨兵都参与，只需要选出个leader，由leader负责进行slave升级到master的过程。

假设有三个哨兵节点 s1,s2,s3

1. 每个哨兵节点都给其他的所有哨兵节点发起一个拉票请求。
2. 收到拉票请求的节点，会回复一个拉票响应，结果有两个：投或者不投。
3. 一轮投票完成之后，得票数超过半数的节点自动成为leader。
4. leader节点负责挑选一个slave成为新的master，当其他的哨兵节点发现新的master出现了，就说明选举结束了。

这个过程涉及到Raft算法，核心就是”先下手为强“，水仙发出拉票请求，大概率就能成为leader。

leader挑选出合适的slave成为新的master

挑选规则：

1. 比较优先级，优先级高的（数值小的）上位，优先级就是配置文件中的slave-priority或者replica-priority。
2. 比较replication offset，谁复制的数据多，高的上位。
3. 比较run id，谁的id小，谁上位。

小结：哨兵的注意事项

• 哨兵节点不能只有一个，否则哨兵节点挂了会影响系统的可用性。
• 哨兵节点最好是奇数个，方便选举leader，的票更容易超过半数。
• 哨兵节点不负责存储数据，仍然是redis主从节点负责存储。
• 哨兵+主从复制解决的问题是”提高可用性“，不能解决”数据在极端情况下写丢失“的问题。
•  哨兵 + 主从复制不能提⾼数据的存储容量. 当我们需要存的数据接近或者超过机器的物理内存, 这样的结构就难以胜任了。

为了存储更多的数据，就引入了集群~~