Redis 哨兵机制以及底层原理深入解析，这次终于搞清楚了

前面我们基于实际案例搭建了缓存高可用方案（分布式缓存高可用方案，我们都是这么干的）同时提到了redis主从架构下是如何保证高可用的，讲到了它是通过redis sentinel的机制来实现的。

今天我们就来看看redis sentinel即哨兵机制的相关底层原理以及我们在生产中需要避的坑。

什么是redis sentinel

哨兵在redis集群架构中是一个非常重要的组件，其主要功能有下面这些：

• 集群监控，即时刻监控着redis的master和slave进程是否是在正常工作。
• 消息通知，就是说当它发现有redis实例有故障的话，就会发送消息给管理员
• 故障自动转移，如果redis master 节点宕机了的话，它就会将请求转到slave 节点上，slave升为master。
• 充当配置中心，如果发生了故障转移，它会通知将master的新地址写在配置中心告诉客户端。

sentinel 本身也是分布式部署的，是一个集群去运行的并且节点间相互协调工作，那它是怎么来监控redis的呢？

（1），当发生故障转移的时候，只有大部分哨兵节点同意才会判断你这个master是真的宕机了，这里会涉及到前面讲到的分布式选主，如果忘记了自行看下（面试是不是经常被问到分布式系统核心问题，这一次没人难倒你）（2），如果哨兵部分节点挂了的话，整个哨兵集群依然能工作，这也是确保自身能高可用。

需要知道的哨兵核心点

1. 哨兵集群至少要 3 个节点，来确保自己的健壮性。
2. redis主从 + sentinel的架构，是不会保证数据的零丢失的，它是为了保证redis集群的高可用。
3. 在部署redis主从 + sentinel 架构之前，我们要在测试环境多测试，尽量模拟线上环境。

你可能会问，哨兵集群 2 个节点难道就不行吗？好，如果咱们的哨兵集群只部署了两个节点，那么 quorum=1,

如上图，如果master宕机，sentinel 1 和 sentinel 2 只要有一个认为master宕机就会进行切换，同