超全面 Redis 分布式高可用方案：哨兵机制

超全面 Redis 分布式高可用方案：哨兵机制

开发工作中对于分布式缓存高可用方案（搭建 Redis 缓存高可用方案），Redis 主从架构下是如何保证高可用的呢？

我们知道 Redis 是一个分布式系统，为 Redis 提供高可用性解决方案。那 Redis 服务部署的哨兵模式主要原理是什么，又解决了什么问题呢超全面 Redis 分布式高可用方案：哨兵机制，于是利用时间将相关问题做了整理，相信看完这篇文章，你也可以去给别人做技术分享了。O(∩_∩)O 哈哈~

0. 问题铺垫

在讨论哨兵模式之前，我们先来看一个应用问题： Redis服务主机宕机。

实际使用过程中，会出现宕机的情况（这样会导致没有写服务，只有读服务）。那我们要保证服务的可用redis高可用架构，就需要从其他salve节点中选取一个来作为节点，来继续提供服务能力。

那主要的动作抽象下：

其中存在几个问题：

其实引入 哨兵机制 ，就可以很好解决上述问题。

哨兵-Redis集群

1. 什么是哨兵？

（哨兵）是Redis 的高可用性解决方案：由一个或多个 实例组成的 系统可以监视任意多个主服务，以及这些主服务器属下的所有从服务，并在被监视的主服务进入下线（不可服务）状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

总结一下哨兵的作用：

不断的检查和slave是否正常运行（存活检测、与slave运行情况检测）

当被监控的服务器出现问题时，向其他哨兵、客户端发送通知

断开故障与slave的连接，选取一个slave作为新，将其他slave连接到新的并告知客户端新的服务器地址。

注意：哨兵也是一台Redis服务器，只是不提供数据服务；通常哨兵配置的数量为单数。

2. 哨兵的工作原理

下面主要针对哨兵在进行故障转移过程中经历的三个阶段分别进行阐述。

2.1. 集群监控

step1：哨兵1连接到Redis集群

集群监控

step2：哨兵2加入进来后

集群监控

step3：哨兵3加入后

集群监控

小小总结一下：

2.2. 消息通知

1）节点会通过/slave 节点建立的cmd连接获取其工作状态

2）收到反馈结果之后，会在哨兵内部进行信息的互通

消息通知

2.3. 故障转移

关于故障转移，严格来讲可划分两个步骤： 故障判定 、 故障转移 。

Q1：如何判断一个节点出现故障？

直到主节点故障，哨兵报出 sdown，同时此哨兵还会向其他哨兵发布消息说这个主节点挂了。发送的指令是 is–down-by–port。

其余的哨兵也会发送他们收到的信息并且发送指令 is–down-by–port 到自己的内网，确认一下第一个发送 is–down-by–port 的哨兵说你说的对redis高可用架构，这个家伙确实挂了。

当一个哨兵认为主节点挂了标记的是 sdown，当半数哨兵都认为挂了其标记的状态是 odown。

一个哨兵认为节点挂了称为主观下线（sdown），超半数哨兵认为节点挂了则称为客观下线（odown）。

Q2：如何进行故障转移？

1）首先，哨兵选举出哨兵去处理故障转移

此时选举方式应用的是Raft协议，这个之前有过介绍，感兴趣的同学可以移步了解： 一致性算法Raft 简易入门

2）其次，哨兵从所有的slave节点找出一个作为节点

主要的规则：

假如以上优先级均一致，会考虑其他优先原则：

假如说 的 为 50redis高可用架构， 偏移量为 55，则哨兵就会选择 为新的主节点。

这点类似于职场中的论资排辈，也就说根据 runid 的创建时间来判断，时间早的先上位。

3）数据转移

3. 总结

Redis 主从复制的作用中有这么一句话“主从复制是高可用的基石”，那实现高可用必不可少的就是哨兵和集群。

3.1 的作用

不断的检查和slave是否正常运行（存活检测、与slave运行情况检测）

当被监控的服务器出现问题时，向其他哨兵、客户端发送通知

断开故障与slave的连接，选取一个slave作为新超全面 Redis 分布式高可用方案：哨兵机制，将其他slave连接到新的并告知客户端新的服务器地址。

3.2 的工作方式

若 重新向 的 PING 命令返回有效回复， 的主观下线状态就会被移除。

若没有足够数量的 同意 已经下线， 的客观下线状态就会被移除。