前言
Redis的主从、哨兵模式、集群模式，在前文中都已经有了详细的搭建流程，可谓是手把手教程，也得到了很多朋友的喜欢。由于前文偏向于应用方面，就导致了理论知识的匮乏，我们可能会用了，但却不明所以，所以今天，博主就通过接下里的几篇博客给大家分别讲解Redis哨兵机制的原理和集群模式下的原理。
导读
在开始讲解之前，博主把前面几篇博客的地址放在这里供大家去翻阅：
Java开发 - 让你少走弯路的Redis的主从复制
Java开发 - 让你少走弯路的Redis主从实现单节点哨兵模式
Java开发 - 让你少走弯路的Redis集群搭建
在这三篇Redis内容中，已经从主从到哨兵再到集群给大家一步步做了详细的应用讲解，如果你对Redis的使用还存在一定的问题的话不妨去看看，兴许会有一些新的收获。
多哨兵模式的疑问
在 Redis集群搭建这篇博客的末尾，博主有这么一段话，见下方：
一个sentinel哨兵大家会了，但是多个sentinel哨兵怎么让他们彼此之间也能监听到呢？诚如博主所说，多个哨兵和一个哨兵的使用方法是一样的，只需要监听主节点，其他的，哨兵会自动完成。
不信？博主专门搭建了一个多哨兵的Redis，我们来看看。
这是我的Redis和Sentinel配置文件：
Redis架构如下：
就是简单的一主二从。
Sentinel的架构如下：
我们分别启动三个Redis和三个Sentinel：
至于配置，就和我博客里面的一摸一样，大家可以照着自己做，这里是演示多个sentinel的工作情况。
如果你要是自己看了报文，你就会发现细节：
这个26380的：
这是26379的：
唯一配置变的地方还真有一个，就是在sentinel的配置文件中：
sentinel monitor mymaster 127.0.0.1 6379 2
监听的主节点后面的数字变了，一个sentinel的时候写1，三个sentinel的时候要过半的sentinel认为主节点挂掉才能故障转移和切换，三个，那过半就写2了，如果你有更多sentinel，这个数字也要改变。当然，你写1也行，但可能出现误判的情况。
测试关闭主节点：
已关闭，此时看从节点：
出现了短暂的连接被拒绝的情况，此时我们发现sentinel没有任何变化，大概也就是几秒钟的样子，变化产生了：
此时去看其他的sentinel节点，会发现有明显的选举过程：
此时如果把sentinel6379下线掉之后，会发生什么？我们试试；
大概在几秒后，sentinel做出了反应，同时输出26379离线的通知，但是Redis那边没有任何的反应，这个正常，毕竟不是redis监控哨兵，是吧？
到这里，还需要博主继续下去吗？一切已经说明了问题。 多哨兵的模式按照博主的方式放心用就行了。
到此，多sentinel使用也算是给大家做了演示，加油哦！
Redis哨兵工作原理
从上面的测试来看，当主节点发生故障挂掉之后，大概时间是18s，sentinel感知到故障，执行自动的故障迁移，当然，这个时间是可以自己调整的。为了了解这种工作机制，我们有必要来了解下sentinel的三种定时监控任务。
INFO指令获得最新节点拓扑图
每个sentinel每隔10s就会向主节点发送INFO命令，然后获取整个Redis节点的拓扑图，这也是为什么，当有节点退出，或有节点加入时，sentinel能极快的感知到拓扑图变化的原因，也是我们只需要指定主节点而不需要指定从节点的原因。
此时还没有完，sentinel通过INFO命令感知到拓扑图后，就发现了主节点下的其他从节点，等到下个10s后，就会同时向主节点和从节点发送INFO命令，以达到监听所有redis节点的目的。
此处应该有图，但是我好懒，我觉得大家应该明白了这个道理了吧？
通过发布订阅获得Master节点和其他Sentinel的信息
每个sentinel间隔2s会向指定频道发送自己关于主节点是否正常的判断，同时还包含当前sentinel节点的信息，其他sentinel通过订阅这个频道就可以达到信息共享的目的，此时就可以判断master节点是不是活的，sentinel节点是不是活的。
解释下关于订阅频道的理解，对于监视同一个主节点的多个Sentinel来说，一个Sentinel发送的信息会被其他Sentinel接收到，这其他Sentinel会根据这些信息来做出对master和对应sentinel的判断。我们可以认为他们是通过主节点达到数据共享的。
我们暂时就理解到这里，不再做更多深层的源码方面的理解。
但当博主打开了sentinel26379的配置文件，偶然在最末位发现了这几段自动生成的配置，似乎打开了新世界的大门：
known- sentinel就是知道另一个sentinel，这都是自动完成的，其原理博主不得，但猜测是通过Master节点完成的数据的共享，上图似乎也是一个对我们假设的印证。
PING指令⼼跳检测
每个Sentinel每隔1秒会向所有节点（ Sentinel 节点、 Master 节点、 Slave 节点）发送PING指令来进⾏⼼跳检测。
选举过程
- 在上面的案例中，当一个sentinel节点认为Master不可用时，会进行主观下线，但并不会真的下线，而是继续通过sentinel is-masterdown-by-addr指令来获取其他sentinel对Master节点的判断，如果最终判断的值达到了我们设置的quorum值，Master节点就被判定为客观下线；
- Leader Sentinel（每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的leader,选举是先到先得）会从原来的Master的Slave中选出一个做为新的主节点
- 首先过滤所有主观下线的节点；
- 选择slave-priority最高的节点，有的话返回，没有的话继续；
- 选择复制偏移量offset最⼤的节点，有的话返回，没有的话继续；
- 选择run_id（服务器运⾏ ID）最⼩的节点，
- 最终选出一个节点，Leader Sentinel节点会通过 SLAVEOF NO ONE命令，让选择出来的Slave变为新的Master，再通过SLAVEOF命令让其他还活着的节点成为新的Master的Slave节点。
最后推荐一篇文章，我觉得讲解通信的过程讲的很详细：一文读懂Redis的哨兵机制 - 知乎
好东西当然是要一起分享了。文章来源：https://www.toymoban.com/news/detail-580606.html
结语
写到这里，Redis的哨兵模式基本是给大家讲解清楚了，不知道你get到了多少？如果还有其他疑问，不放评论区留言和小伙伴们一起讨论吧，最后，不要吝啬你们的赞，动动小手，给博主一个大大的支持吧。文章来源地址https://www.toymoban.com/news/detail-580606.html
到了这里，关于Java开发 - 深入理解Redis哨兵机制原理的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
