Redis-Sentinel

前言

为什么要使用Sentinel（哨兵）？

首先我们要清楚主从切换技术的方法：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

一、哨兵简介

Sentinel（哨兵）是用于监控redis集群中Master状态的工具，其已经被集成在redis2.4+的版本中，是Redis官方推荐的高可用性解决方案。

1.1 哨兵作用

• Master状态检测；
• 如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave；
• Master-Slave切换后，sentinel.conf的监控目标会随之调换。

1.2 工作模式

1. 每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令；
2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel 标记为主观下线；
3. 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态；
4. 当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。

二、主观下线和客观下线

2.1 主观下线

Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。在默认情况下，Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例（主服务器、从服务器、其它Sentinel）发送ping命令，并通过相应的回复判断实例是否在线。

如上图：

• 哨兵1向哨兵2、哨兵3、master、salve1和salve2发送PING命令；
• 哨兵2向哨兵1、哨兵3、master、salve1和salve2发送PING命令；
• 哨兵3向哨兵1、哨兵2、master、salve1和salve2发送PING命令。

相应的Sentinel1、Sentinel2、Master、Slave1、Slave2接收到PING命令后的相应：

• 有效响应：PONG、LOADING、MASTERDOWN其中的一种。
• 无效响应：除了有效响应外的其它响应或者不响应。

如果实例的响应时间超过down-after-milliseconds设置的时间（毫秒），或者响应无效，那么Sentinel会修改这个实例锁对应的实例结构，在结构的flags属性中打开SRI_S_DOWN标识，以此来标识这个实例已经进入主观下线状态。

2.2 客观下线

Objectively Down，简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover，即当Sentinel将一个Master判断为主观下线之后，为了确定这个Master是否真的下线了，它会向同样监视这个Master的其它Sentinel进行询问，看它们是否也认为Master已经进入下线状态（可以是主观下线也可以是客观下线）。当Sentinel从其它Sentinel那里接收到足够数量的已下线判断之后，Sentinel就会将从服务器判断为客观下线，并对主服务器执行故障转移。

总结

通过以上的相关介绍，我们知道了Sentinel给我们的Redis集群提供了高可用性解决方案： 由一个或多个Sentinel实例（instance）组成的Sentinel系统（system），可以监视任意多个主服务器，以及这些主服务器下属的从服务器，并在被监视的主服务器进入下线状态后，自动将下线服务器下属的某个从服务器升级为新的主服务器，然后又新的主服务器代替已下线的主服务器继续处理命令请求。在下线的主服务器上线后降为当前主服务器的从属服务器。

同时也介绍了什么是主观、客观下线，以及如何判断Master主观。客观下线的条件。要注意的是，若没有足够数量的Sentinel进程同意Master主服务器下线，Master主服务器的客观下线状态就会被移除。若Master主服务器重新向Sentinel进程发送ping命令返回有效回复，Master主服务器的主观下线状态就会被移除。