Redis集群搭建（哨兵模式）

Hello大家好，今天小编要和大家一起分享一下redis集群搭建的另一种模式——哨兵模式。

在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。

通俗来讲哨兵模式的出现是就是为了解决我们主从复制模式中需要我们人为操作的东西变为自动版，并且它比人为要更及时。

哨兵的行为：

1、监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。

2、自动故障转移（Automatic Failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。

3、配置提供者（Configuration Provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。

4、通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

（其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。）

架构：

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的Redis节点，不存储数据。

数据节点：主节点和从节点都是数据节点

好啦，看了上面的内容，相信大家已经对哨兵有了一定的了解啦，那么老规矩，光说不练假把式，我们一起实战一下吧！！

哨兵实战：

1、首先我们先将主从服务搭建起来哦！这个上节课已经有详细的演示了，还不会的朋友们看一下小编的上一个章节哦！

好啦，现在我们主从已经搭建结束啦，那么接下来就是配置哨兵，并且启动啦。

2、 我们现在就要开始部署哨兵的节点喽

哨兵节点本质上是特殊的Redis节点，关于哨兵的配置呢，我们主要进行这几方面的配置。3个哨兵节点的配置几乎是完全一样的，主要区别在于端口号的不同（18001 / 18002 / 18003）下面以18001节点为例介绍节点的配置和启动方式；配置部分尽量简化：

sentinel monitor mymaster 127.0.0.1 8001 2配置的含义是：该哨兵节点监127.0.0.1这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。哨兵节点的启动有两种方式，二者作用是完全相同的：

redis-sentinel sentinel-18001.conf

redis-server sentinel-18001.conf –sentinel

我们现在已经把哨兵的服务启动了哦！

好啦，那么接下来就是我们的验证时刻啦！端口为8001的这台redis服务是我们的master，我们来看一下！

8001端口的redis服务为主节点，它有两个从节点，那么我们这样子，我们将8001这台redis服务强行kill掉，我们看看哨兵会不会将我们的主从节点自动换掉！

我们可以看到，8002已经变成了主节点，相应的8003也已经变成了8002的从节点。那么我们现在再把8001启动看看会发生什么！

我们可以看到，8001再启动的时候，已经变成了8002的从节点，而此时8002已经拥有了两个从节点，8001和8003哦。

那下面小编就来为大家总结一下哨兵的工作原理哦！

哨兵的工作原理：

关于哨兵的原理，关键是了解以下几个概念：

1、主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。

2、客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。

需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

3、定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：

（1）每10秒通过向主从节点发送info命令获取最新的主从结构；发现slave节点确定主从关系

（2）每2秒通过发布订阅功能获取其他哨兵节点的信息；SUBSCRIBE c2 PUBLISH c2 hello-redis交互对节点的“看法”和自身情况

（3）每1秒通过向其他节点发送ping命令进行心跳检测，判断是否下线（monitor）。心跳检测，是失败判断依据

4、选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。

5、故障转移：选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：

在从节点中选择新的主节点：选择的原则是，

（1）首先过滤掉不健康的从节点；

（2）过滤响应慢的节点

（3）过滤与master断开时间最久的

（4）优先原则：先选择优先级最高的从节点（由replica-priority指定）；如果优先级无法区分，则选择复制偏移量最大的从节点；如果仍无法区分，则选择runid最小的从节点。

（5）更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。将已经下线的主节点（即8001）保持关注，当8001从新上线后设置为新的主节点的从节点

实战建议：

1、哨兵节点的数量应不止一个。一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈；另一方面减少对下线的误判。此外，这些不同的哨兵节点应部署在不同的物理机上。

2、哨兵节点的数量应该是奇数，便于哨兵通过投票做出“决策”：领导者选举的决策、客观下线的决策等。

3、各个哨兵节点的配置应一致，包括硬件、参数等；此外应保证时间准确、一致。

总结：

在主从复制的基础上，哨兵引入了主节点的自动故障转移，进一步提高了Redis的高可用性；但是哨兵的缺陷同样很明显：哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要我们对从节点做额外的监控、切换操作。此外，哨兵仍然没有解决写操作无法负载均衡、及存储能力受到单机限制的问题