Redis学习日记（四）：Redis Sentinel 高可用

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节点中超过 个任务主节点主观下线的时候这个主节点才被当做真正下线，也就是客观下线（odown）。

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

 

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

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

        2、故障转移： 

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

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

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

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