上次讲到了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个步骤：
主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败。
每个Sentinel节点通过定期监控发现主节点出现了故障。
多个Sentinel节点对主节点的故障达成一致，选举出sentinel-3节点作为领导者负责故障转移。
Sentinel领导者节点自动化执行了故障转移。
故障转移后整个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
展示指定
sentinel slaves
展示指定
sentinel sentinels
展示指定
sentinel get-master-addr-by-name
返回指定
sentinel reset
当前Sentinel节点对符合
sentinel failover
对指定
sentinel ckquorum
检测当前可达的Sentinel节点总数是否达到
sentinel flushconfig
将Sentinel节点的配置强制刷到磁盘上，这个命令Sentinel节点自身用得比较多
sentinel remove
取消当前Sentinel节点对于指定
sentinel monitor
这个命令和配置文件中的含义是完全一样的，只不过是通过命令的形式来完成Sentinel节点对主节点的监控。
sentinel set
动态修改Sentinel节点配置选项
sentinel is-master-down-by-addr
Sentinel节点之间用来交换对主节点是否下线的判断，根据参数的不同，还可以作为Sentinel领导者选举的通信方式。
