上次讲到了Redis的主从复制模式，Redis的主从复制模式下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址，对于很多应用场景这种故障处理的方式是无法接受的。Redis从2.8开始正式提供了Redis Sentinel（哨兵）架构来解决这个问题。

哨兵模式

Redis Sentinel的高可用性

当主节点出现故障时，Redis Sentinel能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。

Redis Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给Redis应用方。整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了Redis的高可用问题。

这里的分布式是指：Redis数据节点、Sentinel节点集合、客户端分布在多个物理节点的架构。

拓扑结构

整个故障转移的处理逻辑有下面4个步骤：

1. 主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败。
2. 每个Sentinel节点通过定期监控发现主节点出现了故障。
3. 多个Sentinel节点对主节点的故障达成一致，选举出sentinel-3节点作为领导者负责故障转移。
4. Sentinel领导者节点自动化执行了故障转移。
5. 故障转移后整个Redis Sentinel的拓扑结构图如下所示：

Redis Sentinel的功能：

• 监控：Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。
• 通知：Sentinel节点会将故障转移的结果通知给应用方。
• 主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。
• 配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息。

对于节点的故障判断是由多个Sentinel节点共同完成，这样可以有效地防止误判。Sentinel节点集合是由若干个Sentinel节点组成的，这样即使个别Sentinel节点不可用，整个Sentinel节点集合依然是健壮的。Sentinel节点本身就是独立的Redis节点，只不过它们有一些特殊，它们不存储数据，只支持部分命令。

安装和部署

按照如下图拓扑进行按照部署。

部署数据节点

1、主节点配置和启动

redis-6379.conf

port 6379

daemonize yes

logfile "6379.log"

dbfilename "dump-6379.rdb"

dir "/opt/soft/redis/data/"

2、从节点配置和启动，两个从节点配置类似。

redis-6380.conf

port 6380

daemonize yes

logfile "6380.log"

dbfilename "dump-6380.rdb"

dir "/opt/soft/redis/data/"

slaveof 127.0.0.1 6379

3、确认主从关系

客户端连接主节点，输入info replication命令查看主从关系

$ redis-cli -h 127.0.0.1 -p 6379 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=281,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=281,lag=0

客户端连接从节点，输入info replication命令查看主从关系

$ redis-cli -h 127.0.0.1 -p 6380 info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up

部署Sentinel节点

3个Sentinel节点的部署方法是完全一致的（端口不同）。

redis-sentinel-26379.conf

port 26379

daemonize yes

logfile "26379.log"

dir /opt/soft/redis/data

sentinel monitor mymaster 127.0.0.1 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

Sentinel节点的默认端口是26379。

sentinel monitor mymaster127.0.0.163792配置代表sentinel-1节点需要监控127.0.0.1：6379这个主节点，2代表判断主节点失败至少需要2个Sentinel节点同意，mymaster是主节点的别名。

启动Sentinel节点

Sentinel节点的启动方法有两种：

• 使用redis-sentinel命令：

• 使用redis-server命令加--sentinel参数：

确认

Sentinel节点本质上是一个特殊的Redis节点，所以也可以通过info命令来查询它的相关信息。

$ redis-cli -h 127.0.0.1 -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3

总结生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机上。Redis Sentinel中的数据节点和普通的Redis数据节点在配置上没有任何区别，只不过是添加了一些Sentinel节点对它们进行监控。

哨兵模式API

Sentinel节点是一个特殊的Redis节点，它有自己专属的API。

主要有几个常用API：

• sentinel masters

展示所有被监控的主节点状态以及相关的统计信息

• sentinel master<master name>

展示指定<master name>的主节点状态以及相关的统计信息

• sentinel slaves<master name>

展示指定<master name>的从节点状态以及相关的统计信息

• sentinel sentinels<master name>

展示指定<master name>的Sentinel节点集合（不包含当前Sentinel节点)

• sentinel get-master-addr-by-name <master name>

返回指定<master name>主节点的IP地址和端口

• sentinel reset<pattern>

当前Sentinel节点对符合<pattern>（通配符风格）主节点的配置进行重置，包含清除主节点的相关状态（例如故障转移），重新发现从节点和Sentinel节点。

• sentinel failover<master name>

对指定<master name>主节点进行强制故障转移（没有和其他Sentinel节点“协商”），当故障转移完成后，其他Sentinel节点按照故障转移的结果更新自身配置

• sentinel ckquorum<master name>

检测当前可达的Sentinel节点总数是否达到<quorum>的个数

• sentinel flushconfig

将Sentinel节点的配置强制刷到磁盘上，这个命令Sentinel节点自身用得比较多

• sentinel remove<master name>

取消当前Sentinel节点对于指定<master name>主节点的监控

• sentinel monitor<master name><ip><port><quorum>

这个命令和配置文件中的含义是完全一样的，只不过是通过命令的形式来完成Sentinel节点对主节点的监控。

• sentinel set<master name>

动态修改Sentinel节点配置选项

• sentinel is-master-down-by-addr

Sentinel节点之间用来交换对主节点是否下线的判断，根据参数的不同，还可以作为Sentinel领导者选举的通信方式。