【51CTO.com原创稿件】Redis 主从复制的作用中有这么一句话“主从复制是高可用的基石”，那什么是高可用呢?高可用就是减少系统不能提供的时间，也就是常听到的以 6 个 9 为基准。实现高可用必不可少的就是哨兵和集群。
本文主要围绕如下几个方面介绍哨兵机制：
- 什么是哨兵
- 哨兵的作用
- 如何配置哨兵
- 哨兵工作原理
- 总结
本文实现环境：
- centos 7.3
- redis 4.0
- redis 工作目录 /usr/local/redis
- 在虚拟机进行模拟操作
什么是哨兵
先简单说几句我们在配置主从复制时有一种情况就是主节点宕机了，谁来提供服务呢?
当主节点宕机后主从复制就没有存在的意义了，数据为王的时代没有了数据何谈什么高可用。
这个时候就横空出世了一位老大哥名叫哨兵，老大哥说这个问题我来帮你们处理。
既然主节点 master 作为老大不领你们玩了。我就从你们四个中间再挑选出来一位老大，然后你们跟着他玩。
等不带你们玩的那个老大回来后他的身份就失效了，就不再是你们的老大了。他只能跟着我挑选出来的老大玩。
上边这段对话过程就是我们配置哨兵的意义到底在哪，跟谁玩就是谁给谁数据，知道了哨兵的作用我们就在继续。
最后我们用专业术语来解释一下什么是哨兵：
哨兵，英文名 Sentinel，是一个分布式系统，用于对主从结构中的每一台服务器进行监控，当主节点出现故障后通过投票机制来挑选新的主节点，并且将所有的从节点连接到新的主节点上。
哨兵的作用
上文中我们谈到的对话过程就是哨兵的作用之一：自动故障转移。
谈到作用肯定就是这个哨兵到底在工作中到底干了什么事情。我们先用比较干巴的概念描述一下，然后在下文的工作原理会一一谈到。
哨兵的三个作用：
- 监控：监控谁?支持主从结构的工作一个是主节点一个是从节点，那肯定就是监控这俩个了。监控主节点和从节点是否正常运行;检测主节点是否存活，主节点和从节点运行情况。
- 通知：哨兵检测的服务器出现问题时，会向其他的哨兵发送通知，哨兵之间就相当于一个微信群，每个哨兵发现的问题都会发在这个群里。
- 自动转移故障：当检测到主节点宕机后，断开与宕机主节点连接的所有从节点，在从节点中选取一个作为主节点，然后将其他的从节点连接到这个最新主节点的上。并且告知客户端最新的服务器地址。
这里有一个注意点，哨兵也是一台 Redis 服务器，只是不对外提供任何服务。配置哨兵时配置为单数。
那么为什么配置哨兵服务器的数量为单数呢?带着这个疑问你会在下文看到你想要的答案。
如何配置哨兵
准备工作
我们开始配置哨兵，开启八个客户端，三个哨兵、一个主节点、俩个从节点、一个主节点客户端、一个从节点客户端。
sentinel.conf 配置解读
哨兵使用的配置文件是 sentinel.conf，如下图：
我们来对 sentinel.conf 配置信息进行解读：
但是大多数都是注释，这里给大家提供一个命令来过滤这些无用信息：
- cat sentinel.conf | grep -v '#' | grep -v '^$'
①port 26379：对外服务端口号。
②dir /tmp：存储哨兵的工作信息。
③sentinel monitor mymaster 127.0.0.1 6379 2：监控的是谁，名字可以自定义，后边的 2 代表的是，如果有俩个哨兵判断这个主节点挂了那这个主节点就挂了，通常设置为哨兵个数一半加一。
④sentinel down-after-milliseconds mymaster 30000：哨兵连接主节点多长时间没有响应就代表挂了。后边 30000 是毫秒，也就是 30 秒。
⑤sentinel parallel-syncs mymaster 1：这个配置项是指在故障转移时，最多有多少个从节点对新的主节点进行同步。
这个值越小完成故障转移的时间就越长，这个值越大就意味着越 多的从节点因为同步数据而不可用。
⑥sentinel failover-timeout mymaster 180000：在进行同步的过程中，多长时间完成算有效，系统默认值是 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
测试主从复制处于正常工作状态，启动三台 redis 服务器，端口分别为 6379、6380、6381：
查看主节点信息，是有俩台从节点在连接着，端口分别为 6380、6381。
这里有一个小小的点就是 lag 怎么一个是 1 一个是 0 呢?lag 是延迟时间，我这里是本地测试所以会出现 0 的情况，使用云服务器是很少出现的。
lag 的值为 0 和 1 都属于正常。
测试主节点添加一个 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 也会有。
直到这里我们对哨兵的配置就结束了，接下来我们把主节点 Master 给宕掉。
等待 30 秒后我们来到 26379 哨兵的客户端，这里新增了一些信息，那么这些信息都做了什么呢?让我们细细道来。
这里边的信息我们先需要知道几个：
①+sdown：这个信息后是指三个哨兵里边有一个认为主节点宕机了。
②+odown：这个信息是指其他俩个哨兵去连接了一下主节点，发现确实是主节点宕机了，然后发起了一轮投票。这里使用的是 redis 4.0，版本之间这块信息有点差异。
③+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380：直到这里是哨兵发起投票的结果，推选端口为 6380 的 redis 为主节点。
④+slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380：这里就把端口为 6381 与 6379 和新的主节点 6380 做了一个连接。
⑤+sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380：最后一句是端口为 6379 的还是没有上线，于是给踢下线。
当我们在重新把 6379 的 redis 服务器上线后，就可以看到哨兵服务端响应了俩句。一句是去除 6379 的下线。最后一句就是重连 6379 到新的主节点上。
这个时候主节点就是 6380 了，在 6380 的 redis 客户端设置值，检测主从复制是否正常工作。
在新的主节点 6380 添加 list 类型：
在 6379 和 6381 获取这个值，至此，我们的哨兵模式就配置完成了。
哨兵工作原理
配置完哨兵后，就需要对其工作原理进行解析了，只有知道其工作流程，才能对哨兵有更好的理解。
本文讲解原理没有那么干巴!让你可以把一篇技术文章当故事去看。
进入正题，哨兵作用是监控、通知、故障转移。那么工作原理也是围绕这三点来讲的。
监控工作流程
监控工作流程如下：
①哨兵发送 info 指令，并且保存所有哨兵状态，主节点和从节点的信息。
②主节点会记录 redis 实例的信息，主节点记录的信息跟哨兵记录的信息看起来是一样的，实际上还是有点区别。
③哨兵会根据在主节点拿到的从节点信息，给对应的从节点也发送 info 指令。
④接着哨兵 2 来了，同样的也会给主节点发送 info 指令，并且建立 cmd 连接。
⑤这个时候哨兵 2 也会保存跟哨兵 1 一样的信息，只不过是保存的哨兵信息是 2 个。
⑥这个时候为了每个哨兵的信息都一致它们之间建立了一个发布订阅。为了哨兵之间的信息长期对称它们之间也会互发 ping 命令。
⑦当再来一个哨兵 3 时，也会做同样的事情，给主节点和从节点发送 info。并且跟哨兵 1 和哨兵 2 建立连接。
通知工作流程
sentinel 会给主从的所有节点发送命令获取其状态，并且会把信息发布到哨兵的订阅里。
故障转移原理
哨兵会一直给主节点发送 publish sentinel：hello，直到哨兵报出 sdown，这个词这会是有不是有点熟悉了。没错就是我们上文中把主节点断开后哨兵服务端报出的信息。
哨兵报出主节点 sdown 后还没有完，哨兵还会往内网里发布消息说明这个主节点挂了。发送的指令是 sentinel is-master-down-by-address-port。
其余的哨兵接收到指令后，主节点挂了吗?让我去看看到底挂没挂。发送的信息也是 hello。
其余的哨兵也会发送他们收到的信息并且发送指令 sentinel is-master-down-by-address-port 到自己的内网，确认一下第一个发送 sentinel is-master-down-by-address-port 的哨兵说你说的对，这个家伙确实挂了。
当所有人都认为主节点挂了后就会修改其状态为 odown。当一个哨兵认为主节点挂了标记的是 sdown，当半数哨兵都认为挂了其标记的状态是 odown。这也就是配置哨兵为什么配置单数的原因。
对于一个哨兵认为主节点挂了称之为主观下线，半数哨兵认为主节点挂了称之为客官下线。
一旦被认为主节点客官下线后，哨兵就会进行下一步操作：
这时哨兵已经检测到问题所在了，那么到底是那个哨兵去负责推选新的主节点呢!不能是张三也去，李四也去，王五也去，这样就乱套了、于是就需要在所有的哨兵里选出领头的，那么是如何选的呢!请看下图。
这个时候，五个 sentinel 就在一起开会了，所有的哨兵都在一个内网中，然后他们会做一件事情就是五个 sentinel 会同时发送指令 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，就会根据优先原则来进行筛选：
- 首先会根据优先级，如果优先级一样在进行其他判断。
- 判断 offset 偏移量，判断数据同步性，假如说 slave4 的 offset 为 90，slave5 偏移量为 100。
那么哨兵就会认为 slave4 的网络是不是有问题，于是就会选 slave5 为新的主节点。那如果说是 slave4 和 slave5 的 offset 相同呢!还有最后一个判断。
- 最后一步就是判断 runid 了，也就是职场中的论资排辈了，也就说根据 runid 的创建时间来判断，时间早的上位。
选出新的主节点后就要对所有的节点发送指令了。
总结
关于哨兵的所有知识点就已经说完了，本文最重要的就是哨兵的工作原理了。
我们在简单的梳理一下其工作原理：
- 首先进行监控，并且所有的哨兵同步信息。
- 哨兵向订阅里边发布信息。
- 故障转移：哨兵发现主节点下线→哨兵开启投票竞选负责人→由负责人推选新的主节点→新的主节点断开原主节点，并且其他的从节点连接新的主节点，原主节点上线后作为从节点连接。
以上就是笔者对哨兵的理解，如果错误欢迎指出，以便及时改正。
作者：咔咔
简介：从业三年，从搬砖一样的生活方式换成了现在有“单”而居的日子。当然这个单不是单身的单!虽然极尽苛刻的技术学习但也远不及客户千奇百怪的要求。进入了朝九晚六，虽然躲过了风吹日晒，但是仍然很享受那些熬得只剩下黑眼圈的日子。坚持学习、坚持写博、坚持分享是咔咔从业以来一直所秉持的信念。希望在诺大互联网中咔咔的文章能带给你一丝丝帮助。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
