前言
上一篇博客中,我们详细介绍了Redis的主从模式Redis主从复制-CSDN博客
在主从模式中,写操作主要依赖于主节点,且只能有一个主节点,一旦主节点挂了,则无法进行写操作,且需要通过人工进行恢复
通过人工进行恢复有着不可靠性,那么,我们有没有什么方法通过自动化的手段来解决主节点挂了的问题.
有的兄弟,有的,Redis中,哨兵机制就是用来解决这个问题
一.哨兵机制
哨兵节点会与主从节点建立起TCP长连接,通过长连接对节点实施监控,分为以下步骤:
1.主观下线
哨兵节点对监控的数据节点定期发心跳包(可自行在配置文件中定义时长),如果心跳包并没有如期而至,则该哨兵节点会认为该数据节点主观下线
2.客观下线
一个哨兵节点发现主节点挂了后,并不能认为该节点真的挂了(可能有网络波动),此时需要多个哨兵共同判断,若多个哨兵节点共同认为节点挂了,则为客观下线
3.选举leader
在判断出节点客观下线后,哨兵们会选举出一个leader(一般为第一个监控到主节点挂了的哨兵),由这个leader在可选的从节点中选出新的主节点
新主节点的选举会根据slave-priority(从节点优先级),offset大小(大的优先),runid来进行
4.配置新主节点
在选出主节点后,哨兵会自动操作该主节点执行slaveof no one,并控制其他节点修改slaveof到新的主节点,最后会自动通知客户端程序,告知新节点的信息,并且后续客户端写操作就会针对新的主节点进行.
注意:
- 哨兵节点不能只有一个,否则哨兵节点挂了也会影响系统的可用性
- 哨兵节点最好有奇数个,方便选举出leader,得票数更容易过半数
- 哨兵节点不负责存储数据,仍然是redis主节点进行存储数据
- 哨兵+主从复制解决的问题是"提高可用性",不能解决"数据极端情况下丢失的问题"
- 哨兵+主从复制不能解决数据存储容量的问题,难以解决存储数据>机器的物理内存