redis主从复制的作用中有这么一句话“主从复制是高可用的基石”，那什么是高可用呢！高可用就是减少系统不能提供的时间，也就是常听到的以6个9为基准。实现高可用必不可少的就是哨兵和集群。本文主要介绍哨兵机制。 咔咔整理了一个路线图，打造一份面试宝典，准备按照这样的路线图进行编写文章，后期发现没有补充到的知识点在进行添加。也期待各位伙伴一起来帮助补充一下。评论区见哦！ 先简单说几句我们在配置主从复制时有一种情况就是主节点宕机了，谁来提供服务呢！ 当主节点宕机后主从复制就没有存在的意义了，数据为王的时代没有了数据何谈什么高可用。 既然主节点master作为老大不领你们玩了。我就从你们四个中间再挑选出来一位老大，然后你们跟着他玩。 等不带你们玩的那个老大回来后他的身份就失效了，就不在是你们的老大了。他只能跟着我挑选出来的老大玩。 上边这段对话过程就是我们配置哨兵的意义到底在哪，跟谁玩就是谁给谁数据，知道了哨兵的作用我们就在继续。 「最后我们用专业术语来解释一下什么是哨兵。」 哨兵，英文名sentinel,是一个分布式系统，用于对主从结构中的每一台服务器进行 上文中我们谈到的对话过程就是哨兵的作用之一自动故障转移。 谈到作用肯定就是这个哨兵到底在工作中到底干了什么事情。我们先用比较干巴的概念描述一下，然后在下文的工作原理会一一谈到。 哨兵的三个作用 这里有一个注意点，哨兵也是一台redis服务器，只是不对外提供任何服务。 配置哨兵时配置为单数。那么为什么配置哨兵服务器的数量为单数呢？带着这个疑问你会在下文看到你想要的答案。 这一章我们就开始配置哨兵，前期工作准备。下图就是咔咔的准备工作。开启8个客户端，三个哨兵、一个主节点、俩个从节点、一个主节点客户端、一个从节点客户端。 哨兵使用的配置文件是 使用命令 测试主从复制处于正常工作状态，启动三台redis服务器，端口分别为 这里有一个小小的点就是lag怎么一个是1一个是0呢！lag是延迟时间，我这里是本地测试所以会出现0的情况，使用云服务器是很少出现的。lag的值为0和1都属于正常。 经过测试我们的主从结构是正常运行的。 直到这里我们对哨兵的配置就结束了，接下来我们把主节点master给宕掉 当我们在重新把6379的redis服务器上线后，就可以看到哨兵服务端响应了俩句。一句是去除6379的下线。最后一句就是重连6379到新的主节点上。 在新的主节点6380添加list类型 配置完哨兵后，就需要对其工作原理进行解析了，只有知道其工作流程，才能对哨兵有更好的理解。 本文讲解原理没有那么干巴！让你可以把一篇技术文章当故事去看。 进入正题，哨兵作用是监控、通知、故障转移。那么工作原理也是围绕这三点来讲的。 Sentinel会给主从的所有节点发送命令获取其状态，并且会把信息发布到哨兵的订阅里。 这时哨兵已经检测到问题所在了，那么到底是那个哨兵去负责推选新的主节点呢！不能是张三也去，李四也去，王五也去，这样就乱套了、于是就需要在所有的哨兵里选出领头的，那么是如何选的呢！请看下图。 这个时候呢！五个sentinel就在一起开会了，所有的哨兵都在一个内网中，然后他们会做一件事情就是五个sentinel会同时发送指令 先把不在线的干掉 关于哨兵的所有知识点就已经说完了，本文最重要的就是哨兵的工作原理了。我们在简单的梳理一下其工作原理。 首先进行监控，并且所有的哨兵同步信息 哨兵向订阅里边发布信息 故障转移 以上就是咔咔对哨兵的理解，如果错误可以提出，咔咔及时改正。 坚持学习、坚持写博、坚持分享是咔咔从业以来一直所秉持的信念。希望在偌大互联网中咔咔的文章能带给你一丝丝帮助。我们下期再见。
❝
前言
❝
本文主要围绕如下几个方面介绍哨兵
本文实现环境
一、什么是哨兵
这个时候就横空出世了一位老大哥名叫哨兵，老大哥说这个问题我来帮你们处理。监控，当主节点出现故障后通过投票机制来挑选新的主节点，并且将所有的从节点连接到新的主节点上。
二、哨兵的作用
监控、通知、自动转移故障
二、如何配置哨兵
1. 准备工作
2. sentinel.conf配置解读
sentinel.conf
我们来对sentinel.conf配置信息进行解读
但是大多数都是注释，这里咔咔给大家提供一个命令来过滤这些无用信息 cat sentinel.conf | grep -v '#' | grep -v '^$'
3. 开始配置
cat sentinel.conf | grep -v '#' | grep -v '^$' > ./data/sentinel-26379.conf把sentinel.conf过滤后的信息移到/usr/local/redis/conf下
然后打开sentinel-26379.conf修改信息存放目录
然后快速的复制俩个哨兵配置文件，端口为26380和26381。sed 's/26379/26381/g' sentinel-26379.conf > sentinel-26381.conf
6379、6380、6381
查看主节点信息，是有俩台从节点在连接着，端口分别为6380、6381。
测试主节点添加一个hash值，hset kaka name kaka
分别从slave1和slave2获取kaka的值，检测主从复制是否正常运行。
启动一个哨兵redis-sentinel 26379-sentinel.conf
连接26379哨兵，主要是最后一行，监控的主节点名为mymaster，状态正常，从节点有俩个，哨兵数量为1个
在来查看一下26379的哨兵配置信息，这个时候已经改动了
在启动一个26380的哨兵，redis-sentinel 26380-sentinel.conf,这里注意一下最后一行多了一条信息，这个id就是我们26379配置文件新增的id
然后我们来到哨兵26379的客户端，同样也是新增的26380哨兵的id
这个时候我们在查看一下26379哨兵的配置文件，第一次查看配置文件是没有配置26380哨兵的，第二次查看时配置了26380哨兵后添加的信息。
最后我们需要把哨兵客户端3启动起来，端口号为26381。启动起来之后，我们的配置信息和服务端的信息也会改动，添加哨兵26380有的信息，哨兵26381也会有。
等待30秒后我们来到26379哨兵的客户端，这里新增了一些信息，那么这些信息都做了什么呢！让我们细细道来。
这里边的信息我们先需要知道几个
这个时候主节点就是6380了，在6380的redis客户端设置值，检测主从复制是否正常工作。
在6379和6381获取这个值，至此呢！我们的哨兵模式就配置完成了。
三、哨兵工作原理
1. 监控工作流程
2. 通知工作流程
3. 故障转移原理（本文重点）
sentinel is-master-down-by-address-portsentinel is-master-down-by-address-port到自己的内网，确认一下第一个发送sentinel is-master-down-by-address-port的哨兵说你说的对，这个家伙确实挂了。当所有人都认为主节点挂了后就会修改其状态为odown。当一个哨兵认为主节点挂了标记的是sdown，当半数哨兵都认为挂了其标记的状态是odown。这也就是配置哨兵为什么配置单数的原因。
❝
sentinel is-master-down-by-address-port并且携带上自己竞选次数和runid。
每个sentinel既是参选者也是投票者，每个sentinel都有一票，信封就代表自己的投票权。
当sentinel1和sentinel4同时把指令发送到群里准备竞选时，sentinel2这个时候就说我先接到谁的指令就把票投给谁。假如sentinel1发的早，那么sentinel2的票就会投给sentinel1。
按照这样的规则一直发起投票直到有一个sentinel的票数为总sentinel数量的一半之多。假设说是sentinel1的票数满足总哨兵数量的一半之多后，sentinel1就会当选。这个时候就进行到了下一个阶段。
在上边哨兵已经选出了sentinel1为代表去所有的从节点找出一个作为主节点。这个挑选主节点不是随便拿一个是有一定的规则的。
响应慢的干掉，sentinel会给所有的redis发送信息，响应速度慢的就会被干掉
与原主节点断开时间最久的干掉，这里由于演示不够用了，所有新增了一个slave5，没有任何意义哈！
以上三个点都判断结束后还有salve4和slave5，就会根据优先原则来进行筛选。
选出新的主节点后就要对所有的节点发送指令了。
四、总结
❝
推荐：《Redis教程》
