Redis系列：高可用之Sentinel(哨兵模式）

1 背景

我们知道，为Redis配置主从模式，可以大幅度的提高Redis服务的可用性，减少甚至避免Redis服务发生宕机的可能。

它有如下能力：

• 故障隔离和恢复：无论主节点或者从节点宕机，其他节点依然可以保证服务的正常运行，并可以手动切换主从。
• 读写隔离：Master 节点提供写服务，Slave 节点提供读服务，分摊流量压力，均衡流量的负载。
• 提供高可用保障：主从模式是高可用的最基础版本，也是哨兵模式和 cluster模式实施的前置条件。

但是依然存在不小的问题，我们知道，在衡量系统可用性这边有个指标叫做MTTR，即平均修复时间。虽然主从模式支持手动切换，但是我们从知道服务故障到手动切换止损到恢复，这可能是一个比较长的过程。这期间的损失将难以计量，对于超高并发大系统是一个绝对灾难。所以我们需要系统自动的感知到Master故障，并选择一个 Slave 切换为 Master，实现故障自动转移的能力。

平均修复时间（Mean time to repair，MTTR），是描述产品由故障状态转为工作状态时修理时间的平均值。

2 什么是哨兵模式

在实际生产环境中，服务器难免会遇到一些突发状况：服务器宕机，停电，硬件损坏等等，一旦发生，后果不堪设想。

哨兵模式的核心还是主从模式的演变，只不过相对于主从模式在主节点宕机导致不可写的情况下，多了探活，以及竞选机制：从所有的从节点竞选出新的主节点，然后自动切换。竞选机制的实现，是依赖于在系统中启动sentinel进程，对各个服务器进行监控。如下图所示：

3 哨兵模式的主要职责

我们知道，要让Redis服务实现故障自动切换会有很多细节需要考虑，比如：

• 判定节点故障的条件是什么，有没有可能是假死或者响应延迟。
• 既然是竞选机制，那么所有slave节点都可以参与竞争，也都有机会成为master。选择哪个slave成为master是关键。
• 竞选出新的master，其他slave需要从新的master中replicaof，所以消息通知和通信也是核心。

带着这些思考，我们来看看官方对Redis哨兵的定义：

哨兵作为 Redis 的一种运行模式，专注于对 Redis 实例（master、slaves࿰