Redis Sentinel
一、Redis Sentinel的由来,普通主从复制高可用?
首先我们复习下主从复制的作用:
1、数据备份 ===》 当主节点挂了的时候,因为有从节点的备份保证了数据的安全性。
2、请求分流 ===》 通过读写分离的方式将客户端的请求分流减轻单节点模式下的压力。
但是这样也存在着问题:
1、当主节点挂了的时候得手动转移,将从节点的其中一个设为主节点。(redis-sentinel 可以解决)
2、主节点只能一台,限制了写入的效率。(分布式解决,redis-cluster 解决)
为什么要用 Redis-Sentinel,我们再说下手动转移有什么问题:
1、怎么判定主节点的故障?
2、如何通知之前连接老主节点的客户端改为现在的客户端?
3、如何保证这里手动转移一整套流程的事务性?
上述虽然可以用脚本实现,但是要把整个故障转移脚本各个方面都考虑完美的话还是不容易。
那现在 Redis-Sentinel 就能解决这些问题。
二、实现原理
我们可以通过上图看到Redis Sentinel 是怎么实现高可用的:
首先 监控主从:Redis sentinel 通过 3 个定时任务完成对 主节点,从节点,sentinel (对的,实际上所有都监控)的监控。
1、每隔10秒,通过向主节点发送 info 命令, 从节点的信息。 (意义:实时维护主从节点的拓扑关系)
2、每隔2秒,sentinel 会向主节点的 __sentinel__:hello 频道 推送 当前sentinel 对主节点的判断 并订阅 这个频道获取其他sentinel对于主节点的判断信息。(意义:发现新的sentinel节点信息 和 sentinel 节点间交换节点信息为选取领导者做准备)
3、每隔1秒,sentinel 会对其余sentinel,master,slave 节点发送ping命令 来进行心跳检测,检查这些节点是否正常(主观下线的依据)。
前两个定时任务都是为了维护主从节点关系和sentinel节点关系做准备,真正发现问题的是 第三个定时任务。
接着是发现故障:sentinel 在执行ping 心跳检测的时候,如果被检测节点超过 down-after-milliseconds 时间都没回复,则当前sentinel认为这个被检测节点 主观下线(sdown),主观下线是一家之言,可能存在误判。
当这个sentinel 节点发现这个被检查是主节点的时候,会通知其他sentinel 去检查这个主节点是否下线,当所有sentinel节点中超过 <quorum> 个任务主节点主观下线的时候这个主节点才被当做真正下线,也就是客观下线(odown)。
注意:这里如果检查到出问题的节点是从节点或者sentienl 节点时,sentinel 进行主观下线后即不存在后续的操作。
最后是解决故障:解决故障有两个步骤:
1、因为去真正去处理故障只需一个sentinel即可,所以这时需要选一个sentinel 领导人,Redis 采用 Raft算法实现,大致步骤可以参考《Redis开发与运维》p259 :
2、故障转移:
a:发现最合适的从节点。先过滤不健康(主观下线,断线,超时等)的slave节点,选择slave-priority(从节点优先级)最高的,不存在最高的优先级的时候返回复制偏移量最大的从节点(复制的最完整)。复制偏移量模糊的可以看我的 redis学习日记(三):Redis 主从复制
b:先执行 slavof no one 成为主节点。
c:再将这个新的主节点成为剩余从节点的主节点。
d:将原来的主节点更新为从节点,并保持关注,等其恢复后去复制新的主节点。