前言

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

笔者的知识脉络

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

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

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

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

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

哨兵策略的实现原理

哨兵策略如何实现高可用

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

需要部署几台机器

既然哨兵系统是要实现Redis的高可用，那么哨兵系统自己也肯定是要高可用。
哨兵系统实现高可用的方案就是集群，我们为了避免单点故障，就是只能采取多部几台机子。
一般哨兵系统至少需要三台机子。你可以想问，为什么不可以是两台呢，两台我也可以检查心跳啊。一台有故障我就可以马上告知管理员啊。
这就涉及到了哨兵模式“选举领头Sentinel”和“客观下线”这两个功能，都是需要各位哨兵群策群力进行投票的（特别是选举领头Sentinel）。所以至少需要三台机子，机子最好是奇数。

注释：Sentinel 本质上是特殊模式的Redis的服务器，运行的命令与普通Redis服务器命令不同。一个哨兵系统够可以监控多个Redis集群。

现在既然知道了哨兵策略需要几台机器才能实现高可用，那么我们就来讲解下流程吧。

Sentinel机器部署流程

1. 我们会在部署充当哨兵的机子上配置文件。该配置文件主要涵盖Master的ip、port信息。
2. 初始化Sentinel服务器。
   与初始化普通Redis服务器类似，但有些功能不可用：比如set、持久化功能等等，有些功能是Sentinel自己独有的：slaveOf等等。
3. 使用Sentinel专用命令。
   使用sentinelcmds作为命令列表，如INFO、sentinel，有些普通Redis可以执行命令Sentinel执行不了，就是因为sentinelcmds没有包含这些命令。
4. 初始化SentinelState实例结构
   这个实例结构保存中所有Sentinel功能的相关状态，是我们理解哨兵策略的基础，哨兵策略的实现就是对实例结构中的数据进行修改来完成的。