Redis学习日记(四):Redis Sentinel 高可用

Redis Sentinel

 

一、Redis Sentinel的由来,普通主从复制高可用?

 

首先我们复习下主从复制的作用:

1、数据备份  ===》  当主节点挂了的时候,因为有从节点的备份保证了数据的安全性。

2、请求分流  ===》  通过读写分离的方式将客户端的请求分流减轻单节点模式下的压力。

 

但是这样也存在着问题:

1、当主节点挂了的时候得手动转移,将从节点的其中一个设为主节点。(redis-sentinel 可以解决)

2、主节点只能一台,限制了写入的效率。(分布式解决,redis-cluster 解决)

 

为什么要用 Redis-Sentinel,我们再说下手动转移有什么问题:

1、怎么判定主节点的故障?

2、如何通知之前连接老主节点的客户端改为现在的客户端?

3、如何保证这里手动转移一整套流程的事务性?

 

上述虽然可以用脚本实现,但是要把整个故障转移脚本各个方面都考虑完美的话还是不容易。

 

那现在 Redis-Sentinel 就能解决这些问题。

 

二、实现原理

 

Redis学习日记(四):Redis Sentinel 高可用_第1张图片

我们可以通过上图看到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节点中超过 个任务主节点主观下线的时候这个主节点才被当做真正下线,也就是客观下线(odown)

注意:这里如果检查到出问题的节点是从节点或者sentienl 节点时,sentinel 进行主观下线后即不存在后续的操作。

 

最后是解决故障:解决故障有两个步骤:

         1、因为去真正去处理故障只需一个sentinel即可,所以这时需要选一个sentinel 领导人,Redis 采用 Raft算法实现,大致步骤可以参考《Redis开发与运维》p259 :

Redis学习日记(四):Redis Sentinel 高可用_第2张图片

        2、故障转移: 

                 a:发现最合适的从节点。先过滤不健康(主观下线,断线,超时等)的slave节点,选择slave-priority(从节点优先级)最高的,不存在最高的优先级的时候返回复制偏移量最大的从节点(复制的最完整)。复制偏移量模糊的可以看我的 redis学习日记(三):Redis 主从复制

                b:先执行 slavof no one 成为主节点。

                c:再将这个新的主节点成为剩余从节点的主节点。

                d:将原来的主节点更新为从节点,并保持关注,等其恢复后去复制新的主节点。

 

 

 

 

 

 

你可能感兴趣的:(redis)