REDIS哨兵【Sentinel】模式+哨兵的核心知识点+redis哨兵主从切换的数据丢失问题+上一章铺垫的【异步复制数据丢失问题】+【集群脑裂】

1.redis哨兵模式的前言：

一年一度的问题来了，为啥子要用redis的哨兵模式的呢？
简单粗暴的理解下子，顺带开个玩笑，没有理解好，还望不要见笑；

其实redis的哨兵模式，个人理解：只是说法搞大上一点，说的不高级点，和皇帝登基道理差不多【皇帝老头挂了，太子登基，其中有几个机制就是谋权篡位了，1太子觉得皇帝老头要挂了，这就是sdown，总共有三个太子，一致认为皇帝老头子挂了就转成了odown，达成三个太子选举，三个太子需要有其中的一个太子登基成为皇帝老头】

2.redis哨兵架构的相关基础知识

· 哨兵是redis集群架构中非常重要的一个组件，主要功能如下：

1.集群监控，负责监控redis master和slave进程是否能正常工作；
2.消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员 ；
3.故障转移，如果master node挂掉了，会自动转移到slave node上 ；
4.配置中心，如果故障转移发生了，通知client客户端新的master地址；

redis哨兵的一些好处和功能：

· 哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作； · 故障转移时，判断一个master
node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题 ； ·
即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了 ； ·
目前采用的是sentinel 2版本，对已1来说，重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单

哨兵的核心知识点：
1.为什么搭建redis哨兵集群至少要三个节点呢？why？

· 哨兵集群必须要部署2个以上节点 quorum【选举人数】= 1；
· master宕机，s1和s2只要有一个哨兵认为master宕机就可以还能切换，同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2,2个哨兵都是运行着的，就可以允许执行故障转移；
· 【但是如果整个M1和S1运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行，结合下图顺带看一下哨兵的金典3个节点集群】

【经典的3节点哨兵集群】

2.redis哨兵上线前必须要通过大力的测试【redis哨兵模式是不会保证数据的零丢失的只能保证高可用】：

2.1 哨兵至少需要3个实例，来保证自己的健壮性【首先必须要保证redis哨兵的健壮性，要不然高可用还有啥意思】
2.2 哨兵 + redis主从的部署架构，是不会保证数据的零丢失的，只能保证redis集群的高可用性
2.3 对于哨兵+redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。【尽可能的能把线上的数据丢上去实际测试】

redis哨兵主从切换的数据丢失问题【压轴出场】

上图先：异步复制可能产生的数据丢失问题

为啥异步复制的时候，也就是master node将数据异步复制给slave node分支的时候可能会产生数据丢失？？？图看完结合完文字解析一波，恍然大悟，呦西！

异步复制导致的数据丢失
因为master复制数据到slave的复制是异步的，所有可能有部分数据还没有复制到slave，master就宕机了，此时这些部分数据就丢失了。

那么问题来了？怎么办？虽然这种情况只是有可能会发生，但是真的发生了，还丢失了不少的数据，MySQL裸奔，MySQL怕是会吃不消?咋办？？？

异步复制丢失数据的解决方案

为了更好的不然MySQL裸奔，当然得想想有没有衣服穿，冷一点没有关系；首先俺们知道，道高一尺魔高一丈，先把conf配置文件翻一翻，下面：

在redis的conf下面设置这两个参数：
min-slaves-to-write 1
min-slaves-max-lag 10
先来一波参数说明：
min-slaves-max-lag这个配置，就可以确保说，一旦salve复制数据ack延时，就会认为可能maste noder宕机后损失的数据太多了，那么master就会暂时拒绝写的请求，这样可以将master node 宕机时由于部分数据未同步到slave导致的数据丢失降低到课控制的范围内【这个文字可能看的会有点绕，有点虚头巴脑不务实的感觉，上图->异步复制数据的解决方案】

很简单：要求至少有一个slave node，数据复制和同步的延迟不能超过10秒钟如果说一旦所有的slave node，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master node这个分支就不会再接收任何请求了。

【这里的时候，俺也有点小疑惑点，那这不是完犊子了，为啥只保证一个，要是这个时候恰好master出现宕机，正好有选举提升master选到了另外一个master上面去了，这不是很尴尬？那不还是数据丢失了？】—这个别急，上下文要对应，这个要解释在下文中； =留个伏笔=

脑裂导致的数据丢失问题

上图：脑裂是什么？什么情况下会出现这种问题？【集群脑裂导致的数据丢失问题图】

这个基本上见图如解决问题：【脑裂清晰的解释】

脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际在master还运行着，此时哨兵可能就会认为master宕机了，然后开始进行选举，将其他的slave切换成了master，这个时候，集群了就会有两个master，也就是所谓的脑裂；
此时虽然摸个slave被切换成了master，但是可能client客户端还没来得及切换到新的master，还在继续向旧的master写的数据，就可能丢失了，因此就的master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据；

直接上解决方案图：

首先还是conf文件下的两个参数拿出来先：

这里就不过多的做参数说明了，上面有类似的举例
min-slaves-to-write 1
min-slaves-max-lag 10

文本解析：

减少脑裂的数据丢失问题：如果一个master出现了脑裂，跟其他的slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，这个ack说的就是slave node给master node的响应反馈，那么就直接拒绝客户端的写请求【这样脑裂后的旧master就不会接受client客户端的新数据，也就避免了数据丢失】
以上的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求，因此在脑裂的场景下，最多也就丢失10秒中的数据；

凡事没有绝对，但是一定有对应的解决办法，继续深入一波；

redis哨兵的4个核心底层原理，包含slave选举的算法

1.sdown转odown的机制，在文章的前言就解释的很透彻，但是讲的停白话的，专业写来讲，也是差不多的原理，挂个图，立马领悟，啥时候看，啥时候爽；【sdown转odown机制】

2.哨兵和slave集群的自动发现机制
上图后解释：【哨兵和slave集群的自动发现机制】

啥意思呢？努力看完这枯燥点的专业话

1. 哨兵互相之间的发现，是通过redis的pub/sub系统实现的，每个哨兵都会往_sentinel_:hello这个channel你发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在；
2. 每隔两秒钟，每个哨兵都会往自己监控的某master+slaves对应的_sentlinet_:hello channel里发送一个消息，内容是自己的host，ip和runid还有对这个master的监控配置 ；
3. 每个哨兵也会去监听自己监控的每个master+slaves对应的_sentinel_:hello channel,然后去感知到同样在监听这个master+slaves的其他哨兵的存在；
4. 每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步；

3.slave配置的自动纠正

1.哨兵会负责自动纠正slave的一些配置信息，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据；
2.如果salve连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保它们连接到正确的master上；

4.伏笔 前面留下的伏笔就是核心底层原理的第4点，其实也很简单；
如果一个master被认为odown了，而且majority哨兵都允许了主备切换，那么某个哨兵就会执行贮备切换操作，此时就要首选选举一个slave来作为master；

此时会考虑slave node分支的一些信息：

1.跟master断开的连接时长【这不，首选就是这个，当然只用保证一个slave node分支没有和master复制数据超过10秒即可】
如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为maser

2.slave优先级
按照slave优先级进行排序，slave priority越低，优先级就越高

3.复制offset
如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高

4.run id
如果上面两个条件都相同，那么选择一个run id比较小的哪个slave作为master即可

到达了文章的最后，节点就是一份图，关说不练假把式，整起来
【在项目中以经典的3节点方式部署哨兵集群】

声明：转发请备出处！谢谢！所有的原图可以找我申领，redis的生产环境的部署，集群的搭建，哨兵模式，主从分离，redis如何支撑海量数据，几十万的QPS，master node和slave node的主从分离痛点等等，包括小到linux上面的静态IP配置，网段，全部画图笔记，可以无条件分享，谢谢大家。
【欢迎大家的留言和补充指出，希望能在评论区多多交流，分享避免线上环境中的各种踩坑】