为什么至少三个哨兵_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 架构之前，我们要在测试环境多测试，尽量模拟线上环境。

你可能会问&