大厂二面高可用之Redis哨兵策略

前言

笔者在二面某知名大厂时，从Redis的高可用问到kafka的高可用、MySQL的高可用，又让我阐述从高可用的角度设计自己应用程序的高可用，自己回答得不够好，特别是自己项目在QPS陡增时如何设计系统，快速承接大量请求时。
本文针对Redis实现高可用的方法-哨兵策略做了详细介绍和图解，希望大家多提意见和问题。

笔者的知识脉络

• 哨兵策略要解决什么问题（作用）？
• 哨兵策略如何实现？
• • 如何实现哨兵高可用？既然要保证Redis的高可用，那么哨兵自己也要具备高可用。所以第一个我们要说明哨兵如何确保自己高可用。
• • 如何监控Redis集群状态？确保哨兵系统自己不会出问题后，就要监控Redis服务器了。
• • 如何发现服务器故障？哨兵监控的Redis服务器的目的在于发现问题和处理问题，那就要先能发现故障。
• • 如何进行故障转移。既然发现了问题，就要解决问题，故障转移就是哨兵策略解决问题的关键。

哨兵策略要解决什么问题？

背景：我们都知道Redis作为快速缓存，存储在内存中，既然是存储在内存的数据就会面临的数据丢失的问题，那怎么办？Redis提供了两个解决办法，一个是持久化数据到硬盘（后续有需要再讲），一个是高可用。

高可用你就可以很简单的理解，本来我们Redis只部署了一台机器，一旦这台机器挂了，我们的缓存机制就无效了。现在为了防止这个问题，我们部署主从架构，一台Master四台Slave。Redis的主从架构主要是为了提高并发量，主写从读。那么现在问题来了，现在Master机器挂掉了，其他机器都是Slave，没办法写，我们只能读缓存数据了。等下运维发现机子挂了，赶紧帮忙重启，那这段时间的请求怎么办？手动响应是高延迟的一个操作啊。这么一说，你就会发现这样解决问题很蠢。

所以Redis的哨兵机制就是为了解决这个愚蠢的问题。在Redis服务器集群出现问题时及时处理，进行故障转移（主备切换），这就是哨兵策略要解决的最重要的问题。既然我们知道了哨兵模式要解决的问题了，那么我们就学习下哨兵模式是如何解决这个问题了。

哨兵策略的实现原理

哨兵策略如何实现高可用

哨兵集群，哨兵机器通过Sentinel_hello频道自动发现，组成哨兵集群，各哨兵互相监控。

需要部署几台机器

既然哨兵系统是要实现Redis的高