蓝盟IT小贴士，来喽！
此博客简要介绍了redis  sentinel的相关原理，同时在最后一篇文章中提供了“硬核”实战教程，让您在理解原理的基础上，体验真正获得的整个过程。
上一篇文章谈了Redis的主从副本，谈了其原理和缺点，具体建议可以看看我以前写的文章Redis的主从副本。
通常，只有主从复制显然不足以满足Redis在真正复杂的生产环境中的高可用性。 例如，在master节点宕机后进行主从切换时，我们需要手动制作failover。
另一方面，在流量方面，主从架构只能通过添加slave节点来扩展读取请求，“写入能力”不能通过master单节点的资源限制来扩展。
所以有必要引入Sentinel。
Sentinel是Redis的高可用性解决方案之一，本身也是一种分布式体系结构，包括“多个”Sentinel节点和“多个”Redis节点。 每个Sentinel节点监视Redis节点及其多余的Sentinel节点。
当发现某个节点无法到达时，如果是master节点，则与剩下的Sentinel节点进行协商。 如果大多数Sentinel节点认为无法到达master，请选择Sentinel节点，对master执行故障转移，通知与Redis调用方相关的更改。
对于“主从”手动故障转移，Sentinel的故障转移完全自动化，是“不需要”的手动干预。
Sentinel本身具有高可用性
66、那我怎么知道需要部署多少Sentinel节点来满足自己的高可用性？
由于Sentinel本身也是分散的，因此必须部署多个实例以确保群集的高可用性，但这是最小的要求，至少需要“三个”。
我去。 三个只有三个吗？ 今天偏偏只布置了两个
不要单杠.等我说了为什么要三个？ 是.
因为哨兵要执行故障转移必须由“大部分”哨兵同意。 如果只有两个哨兵实例，正常运作的就是这样。
如果有哨兵的机器在切断机房电源、挖掘光纤等极端情况下全部中断，另一个哨兵即使发现master的故障而试图执行故障转移，也得不到“其余的哨兵节点”的同意，此时也是“此时因此，至少需要三个节点来保证Sentinel群集本身的高可用性。 当然，这三个Sentinel节点肯定建议位于“不同”的计算机上。 如果所有Sentinel节点都位于同一台计算机上，则该计算机锁定后，整个Sentinel将不复存在。

文/上海蓝盟 IT外包专家

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: 蓝盟IT外包，关于改进灾难恢复战略的九项建议

• 分享到：