想进大厂拿高薪？掌握 Redis 的 Sentinel 哨兵原理将是至关重要的突破口

• 集群监控

监控 Redis master 和 slave 进程的正常工作

• 消息通知

如果某个 Redis 实例有故障，那么哨兵负责发送报警消息给管理员

• 故障转移

若 master node 宕机，会自动转移到 slave node 上

• 配置中心

若发生故障转移，通知 client 客户端新的 master 地址

哨兵本身也是分布式，作为一个集群运行：

• 故障转移时，判断一个 master node 是否宕机，需要大部分哨兵都同意，涉及分布式选举

• 即使部分哨兵节点宕机，哨兵集群还是能正常工作

目前采用的是 sentinal 2 版本，sentinal 2 相对于 sentinal 1 来说，重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单

哨兵 + Redis 主从的部署架构不保证数据零丢失，只保证 redis 集群的高可用性。

1.1 为何 2 个节点无法正常工作？

必须部署 2 个以上的节点。若仅部署 2 个实例，quorum=1

+----+         +----+| M1 |---------| R1 || S1 |         | S2 |+----+         +----+

Configuration: quorum = 1

master 宕机，s1 和 s2 中只要有 1 个哨兵认为 master 宕机就可以进行切换，同时会在 s1 和 s2 中选举出一个执行故障转移. 但此时，需要 majority，也就是大多数哨兵都是运行的，2 个哨兵的 majority 就是 2

2 个哨兵的 majority=2 3 个哨兵的 majority=2 4 个哨兵的 majority=2 5 个哨兵的 majority=3

2 个哨兵都运行着，就可以允许执行故障转移

若整个 M1 和 S1 运行的机器宕机了，那么哨兵仅剩 1 个，此时就无 majority 来允许执行故障转移，虽然另外一台机器还有一个 R1，但故障转移不会执行

1.2 3 节点哨兵集群

+----+       | M1 |       | S1 |       +----+          |+----+    |    +----+| R2 |----+----| R3 || S2 |         | S3 |+----+         +----+

Configuration: quorum = 2，majority

若 M1 节点宕机了，还剩下 2 个哨兵，S2 和 S3 可以一致认为 master 宕机了，然后选举出一个来执行故障转移

同时 3 个哨兵的 majority 是 2，所以余存的 2 个哨兵运行着，就可执行故障转移

02 Redis Sentinel 架构

2.1 Redis Sentinel 故障转移

1. 多个 sentinel 发现并确认 master 有问题。

2. 选举出一个 sentinel 作为领导。

3. 选出一个 slave 作为 master.

4. 通知其余 slave 成为新的 master 的 slave.

5. 通知客户端主从变化

6. 等待老的 master 复活成为新 master 的 slave

• 可监控多套

03 安装与配置

1. 配置开启主从节点

2. 配置开启 sentinel 监控主节点。(sentinel 是特殊的 redis)

3. 实际应该多机器

4. 详细配置节点

Redis 主节点

[启动]redis-server redis- 7000.conf
[配置]port 7000daemonize yespidfile /var/run/redis-7000.pidlogfile "7000.log"dir "/opt/soft/redis/data/"

Redis 从节点

[启动]redis-server redis-7001.confredis-server redis-7002.conf
slave-1[配置]
port 7001daemonize yespidfile /var/run/redis-7001.pidlogfile "7001.log"dir "/opt/soft/redis/data/"slaveof 127.0.0.1 7000
slave-2[配置]port 7002daemonize yespidfile /var/run/redis-7002.pidlogfile "7002.log"dir "/opt/soft/redis/data/"slaveof 127.0.0.1 7000

Sentinel 主要配置

port $(port)dir "/opt/soft/redis/data/"logfile " $(port).log"sentinel monitor mymaster 127.0.0.1 7000 2sentinel down-after-milliseconds mymaster 30000sentinel parallel-syncs mymaster 1sentinel failover-timeout mymaster 180000

3.1 演示

• 主节点配置

• 重定向

• 打印检查配置文件

• 启动

04 客户端

• 客户端实现基本原理-1

• 客户端实现基本原理-2

• 客户端实现基本原理-3 验证

• 客户端实现基本原理-4 通知(发布订阅))

4.1 客户端接入流程

1. Sentinel 地址集合

2. masterName

3. 不是代理模式

JedisSentinelPool sentinelPool = new JedisSentinelPool(masterName, sentinelSet, poolConfig, timeout);
Jedis jedis = null;try {	jedis = redisSentinelPool.getResource();	//jedis command} catch (Exception e) {	logger.error(e.getMessage(), e);} finally {	if (jedis != null)		jedis.close();}

05 定时任务

1. 每 10s 每个 sentinel 对 master 和 replica 执行 INFO 命令

• 发现 replica 节点

• 确认主从关系

1. 每 2s 每个 sentinel 通过 master 节点的 channel 交换信息(pub/sub)

• 通过 sentinel :java 频道交互

• 交互对节点的"看法”和自身信息

1. 每 1s 每个 sentinel 对其他 sentinel 和 redis 执行 ping

• 心跳检测，失败判定依据

06 主观下线和客观下线

6.1 主观下线(Subjectively Down,SDOWN)

单个 Sentinel 节点对服务器做出的下线判断，即单个 Sentinel 认为某个服务下线（有可能是接收不到订阅，之间的网络不通等一系列原因）。

注意主观下线是每个 sentinel 节点对 Redis 节点失败的"偏见”。所以还需要客观下线机制。

6.2 客观下线(Objectively Down,ODOWN)

多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过命令互相交流之后，得出的服务器下线判断，然后开启 failover。

只有在足够数量( 超过 quorum 个)的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（ODOWN）。只有当 Master 被认定为客观下线时，才会发生故障迁移。

6.3 仲裁

仲裁指配置文件中的 quorum 参数。某个 Sentinel 先将 Master 节点标记为主观下线，然后会将这个判定通过 sentinel is-master-down-by-addr 命令询问其他 Sentinel 节点是否也同样认为该 addr 的 Master 节点要做主观下线。

sentinel monitor <masterName> <ip> < port> <quorum>sentinel monitor myMaster 127.0.0.1 6379 2# sentinel down-after-milliseconds < masterName> < timeout>sentinel down-after-milliseconds mymaster 30000

最后当达成这一共识的 Sentinel 个数达到前面说的 quorum 设置的值时，该 Master 节点会被认定为客观下线并进行故障转移。 quorum 值一般设为 Sentinel 个数的二分之一加 1，例如 3 个 Sentinel 就设为 2。

综上可得

6.4 哨兵工作原理

1. 每个 Sentinel 以 1 次/s 向他所知的 Master，Slave 以及其他 Sentinel 节点发送一个 PING

2. 若一个实例距离最后一次有效回复 PING 的时间超过配置文件 down-after-milliseconds，则该实例会被 Sentinel 标记为 主观下线

3. 若一个 Master 被标记为主观下线，则正在监视该 Master 的所有 Sentinel 会 1 次/s 确认 Master 是否真的进入主观下线状态

4. 当有足够数量 Sentinel（大于等于配置文件指定的值）在指定时间范围内确认 Master 的确进入主观下线状态，则 Master 会被标记为 客观下线

5. 若 Master 处于 ODOWN 状态，则投票自动选出新 Master。将剩余从节点指向新 Master 继续数据复制

6. 在正常情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有 Master，Slave 发送 INFO 命令；当 Master 被 Sentinel 标记为客观下线时，Sentinel 向已下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次；

7. 若没有足够数量 Sentinel 同意 Master 已经下线，Master 的客观下线状态会被移除。若 Master 重新向 Sentinel 的 PING 命令返回有效回复，Master 的主观下线状态就会被移除

07 领导者选举

原因：只有一个 sentinel 节点完成故障转移。 选举：通过 sentinel is-master-down-by-addr 命令都希望成为领导者：

1. 每个做主观下线的 Sentinel 节点向其他 Sentinel 节点发送命令，要求将它设置为领导者

2. 收到命令的 Sentinel 节点如果没有同意通过其他 Sentinel 节点发送的命令，那么将同意该请求，否则拒绝

3. 如果该 Sentinel 节点发现自己的票数已经超过 Sentinel 集合半数且超过 quorum，则将成为领导者

4. 如果此过程有多个 Sentinel 节点成为了领导者，那么将等待一段时间重新选举

• 选举实例

08 故障转移

8.1 领导者节点完成

1. 从 slave 节点中选出一个“合适的"节点作为新的 master 节点

2. 对上面的 slave 节点执行 slaveof no one 命令让其成为 master 节点

3. 向剩余 slave 节点发送命令，让它们成为新 master 节点的 slave 节点，复制规则和 parallel-syncs 参数有关

4. 更新对原来 master 节点配置为 slave，并保持着对其关注，当其恢复后命令它去复制新的 master 节点。

8.2 选择合适的 slave 节点

1. 选择 slave priority(slave 节点优先级)最高的 slave 节点，如果存在划返同，不存在则继续。

2. 选择复制偏移量最大的 slave 节点(复制的最完整)，若存在则返回，不存在则

继续。 3. 选择 runId 最小的 slave 节点。

09 常见开发运维问题

9.1 节点运维

• 机器下线:例如过保等情况

• 机器性能不足:例如 CPU、内存、硬盘、网络等

• 节点自身故障:例如服务不稳定等

主节点 sentinel failover <masterName>

节点下线

• 从节点:临时下线还是永久下线,例如是否做一些清理工作。但是要考虑读写分离的情况。

• Sentinel 节点: 同上。

节点上线

• 主节点: sentinel failover 进行替换

• 从节点: slaveof 即可, sentinel 节点可以感知

• sentinel 节点:参考其他 sentinel 节点启动即可。

从节点的作用

1. 副本：高可用基础

2. 拓展读能力

由于 Redis Sentinel 只会对主节点进行故障转移,对从节点采取主观的下线,所以需要自定义一个客户端来监控对应的事件

三个消息

• +switch-master :切换主节点(从节点晋升主节点)

• +convert-to-slave :切换从节点(原主节点降为从节点)

• +sdown:主观下线。

总结

• Redis Sentinel 是 Redis 的高可用实现方案：

故障发现、故障自动转移、配置中心、客户端通知。

• Redis Sentinel 从 2.8 版本开始才正式生产可用

• 尽可能在不同物理机上部署 Redis Sentinel 的所有节点

• Redis Sentinel 中的 Sentinel 节点个数应该≥3，且最好为奇数，便于选举

• Redis Sentinel 中的数据节点与普通数据节点无差异

• 客户端初始化时连接的是 Sentinel 节点集合，不再是具体的 Redis 节点，但

Sentinel 只是配置中心，并非代理

• Redis Sentinel 通过三个定时任务实现了 Sentinel 节点对于主节点、从节点、

其余 Sentinel 节点的监控

• Redis Sentinel 在对节点做失败判定时分为主观下线和客观下线

• 看懂 Redis Sentinel 故障转移日志对于 Redis Sentinel 以及问题排查非常有帮助

• Redis Sentinel 实现读写分离高可用可以依赖 Sentinel 节点的消息通知,获取 Redis 数据节点的状态变化