redis哨兵架构的基础知识整理

本篇内容介绍了“redis哨兵架构的基础知识整理”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

1. 哨兵的介绍

sentinel ， 中文是哨兵。

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

（1）集群监控：负责监控reidis master 和slave 进程是否正常工作；

（2）消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员；

（3）故障转移：如果master node挂掉了，会自动转移到slave node上；

（4）配置中心：如果故障转移发生了，通知client 客户端新的master 地址；

哨兵本身也是分布式的作为一个哨兵集群去运行，互相协同工作；

（1）故障转移时， 判断一个master node宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题；

（2）即使部分哨兵节点挂了，哨兵集群还是能正常工作的，因为如果 一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就坑爹了；目前采用的是sentinel 2 版本，sentinel2 相对于 sentinel 1 来说，重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单。

2. 哨兵的核心知识

（1）哨兵至少需要3个实例，来保证自己的健壮性；

（2）哨兵+redis 主从的部署架构，是不会保证数据0丢失的，只能保证redis 集群的高可用性；

（3）对于哨兵+redis主从这种负责的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练；

3. 为什么redis 哨兵集群只有2个节点无法正常工作？

哨兵集群必须部署2个以上节点，如果哨兵集群仅仅部署了2个哨兵实例，quorum=1

M1 R1

S1 S2

Configuration：quorum = 1 (哨兵节点只要1个认为宕机就可以进行切换了)

master 宕机，s1 和 s2 中只要有一个哨兵认为宕机就可以进行切换，同时s1和s2中会选举出一个哨兵来进行故障转移，同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2，2个哨兵都运行这，就可以允许执行故障转移，但是整个M1和S2运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行；

4. 经典的3节点哨兵集群

M1

S1

R2 R3

S2 S3

Configuration：quorum = 2 majoiry

如果M1所在机器宕机了，那么3个哨兵还剩下2个，S2和S3可以一致认为master 宕机，然后选举一个来执行故障转移；同时3个哨兵的majoiry = 2 ， 所以还剩下2个哨兵运行着，就可以进行故障转移。

“redis哨兵架构的基础知识整理”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！