redis的主从复制模式下,一旦主节点出现了故障无法提供服务了,需要人工进行主从切换,同时大量的客户端需要被通知切换到新的主节点上,对于有了一定规模的应用来说,这种方案的延迟是无法接受的,于是redis2.8提供了Redis-Sentinel(哨兵)来解决这个问题.
目录
1.啥是哨兵节点:
2.redis数据节点:
3.哨兵节点集合:
4.人工干预处理流程:
5.哨兵节点监控处理及流程:
1.啥是哨兵节点:
哨兵节点是一个独立的redis-sentinel进程,是负责监控redis数据节点的节点.
2.redis数据节点:
主节点和从节点共同成为数据节点.
3.哨兵节点集合:
若干个哨兵节点(redis-sentinel)共同构成的集合.
哨兵节点个数设置:
哨兵节点在使用的时候,可以有一个,也可以使用多个,但一般不会只使用一个,而是若干个哨兵节点构成的集合.共同监控一组数据节点:
1. 是为了防止一个哨兵节点因误判或偶然性的网络问题等做出错误的相应,当多个哨兵节点共同监控,当出现问题时,多个哨兵节点都反馈,提高正确性.
2. 哨兵节点本身也可能出现问题.若哨兵节点只有一个,当这个哨兵节点挂了,后续redis主节点挂了,就无法进行自动恢复过程了.
4.人工干预处理流程:
当主节点出现问题不能提供服务时,
1>.程序员通过监控系统,发现redis主节点故障宕机了.先尝试重启主节点,看能否解决问题,
2>.若主节点问题暂时找不到,就选择一个从节点作为新的主节点(slaveof no one命令),然后修改剩余从节点,连接到新的主节点上(slaveof ip port命令).
3>.告知客户端(修改客户端配置),让客户端能够连接新的主节点,挂到这组机器上.
后续若主节点能正常启动了,就让其作为新的从节点,连接到主节点上.
这一系列操作,对机器来说,延时性是非常高的,手动完成这一系列操作后,至少要半个小时以上,这个过程中,一直无法进行写操作,是无法接受的;
还有,万一在人工操作的过程中,出现了错误操作,可能带来更严重的问题,这都是不可预防的.
于是就更需要引入哨兵机制,通过自动化的方式,让程序对主节点挂了做出处理.
若是从节点挂了,影响不是很大,读写操作都还能正常进行;若是主节点挂了,redis哨兵节点就需要进行处理了.
5.哨兵节点监控处理及流程:
使用多个哨兵节点(计数个),通过建立tcp长连接(定期发送心跳包),一起监控redis数据节点(主,从节点).
1>.监控: 哨兵节点通过监控发现主节点出现问题时,不会立即做出处理,而是向其他哨兵节点确认,多数节点都发现该节点出现故障,就进行处理操作.
这步主要是防⽌该情况：出故障的不是主节点，⽽是发现故障的哨兵节点，该情况经常发⽣于哨兵节点的⽹络被孤⽴的场景下.
2>.监控到主节点出现故障后,从哨兵节点集群中选出一个leader来处理故障转移.
3>.故障转移: leader哨兵节点从 从节点中选出一个作为主节点,让其他从节点同步新主节点；
4>.通知: 哨兵节点通知应⽤层客户端程序,让其转移到新主节点。后续客户端进行读写操作就会针对新的主节点操作了.
redis哨兵的核心功能:
1.监控;
2.自动故障转移
3.通知
哨兵节点的个数:
最好设置成计数个(3个刚好), 这和leader的选举有关和一些别的原因,后续会再细说.
