上文末指出，Redis【主-从】架构的从节点一般仅用于读操作，或纯粹数据备份，这种架构当主节点宕机时，Redis服务将不可用，需重启主节点或手动将从节点升级为主节点以接收写操作。无论采用那种方式都不可保证Redis服务的可用性。故Redis提供了【哨兵】机制，相较于单纯的【主-从】架构，哨兵机制可在Redis主节点宕机后，自动选出可用节点并升级为主节点，供客户端使用。选举和升级时长可配置，一般默认为30s~3min，极大增加了【主-从】架构的可用性。
1，哨兵架构搭建
Redis哨兵仍然是Redis服务，是专门用来监控其他哨兵和主从Redis服务运行状态的Redis服务，配置文件是Redis安装目录下的sentinel.conf文件，启动使用src下redis-sentinel服务启动。
注意：哨兵机制的核心是自动选举。目前市面上所有架构的选举机制，基本都采用了【过半同意机制】，即参与选举的所有哨兵中，当出现超过半数的哨兵选举结果一致时，该结果就是最终结果。
比如：假设有三台Redis服务：A(主), B(从), C(从)，另外有三台哨兵服务D, E, F。当A宕机后，DEF需要从BC中选出一台作为master。如果DEF中任意两个选的结果相同，该结果就会是master，比如DE选择C，F选择B，则C将作为master对外提供服务，B则变为C的从节点。
1.1，搭建步骤
搭建三台Redis服务实现一主两从（步骤见上章），搭建三个哨兵（一般搭建奇数哨兵，方便选举）：
1，复制sentinel.conf文件，分别为sentinel-26379.conf, sentinel-26380.conf, sentinel-26381.conf
cp redis-5.0.0 redis-5.0.0/config/sentinel/sentinel-26379.conf
2，修改配置文件（属性作用将在1.2详解）
port 26379
daemonize yes // 后台运行程序
pidfile var/run/redis-sentinel-26379.pid
logfile "redis-5.0.0/logs/redis-sentinel-26379.log"
dir redis-5.0.0/data/26379
sentinel monitor mymaster 192.168.122.1 6379 2
哨兵配置前 3，启动Redis服务、启动哨兵
src/redis-server config/master-slave/6379.conf
src/redis-sentinel config/sentinel/sentinel-26379.conf
至此，哨兵的架构既已搭建完成。登录6379客户端，通过【info】 命令，可查看当前Redis服务的主从节点信息，如下图：
哨兵架构搭建好后，系统会将当前节点信息记录在各哨兵配置文件，如下图为sentinel-26379.conf：
1.2，sentinel 配置属性详解
哨兵配置后的sentinel.conf文件与哨兵配置前文件有明显不同，配置后除了记录各节点信息，还记录了主节点的选举切换次数等。下面将介绍哨兵配置前后各参数作用：
1.2.1，哨兵配置前属性
sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 192.168.122.1 6379 2
设置哨兵监控的主节点对象，哨兵可从主节点获取所有从节点信息【info replication】
<master-redis-name> : 主节点名称，可任意设置值，客户端访问时会用到；
<master-redis-ip>、<master-redis-port>：主节点IP、端口；
<quorum>: 哨兵选举成功个数。表示当有多少个哨兵认为master宕机时，才表示master真的宕机，修改master运行状态。一般设置个数值为：哨兵个数/2 + 1
sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds 30000
判断节点是否宕机的时间阈值。默认情况下，每个哨兵会以每秒一次的频率向各Redis节点及其他哨兵发送PING命令（心跳机制），通过返回的结果判断对方是否在线，若回复超过该参数设定时间，则判断对方已下线。
sentinel parallel-syncs <master-name> <numreplicats>
sentinel parallel-syncs mymaster 1
新的master选举成功后，从节点将从主节点复制数据。该参数表示新master上线后，同时复制master数据的从节点的个数，即并行复制master数据的从节点个数。
sentinel failover-timeout <master-name> <millseconds>
sentinel failover-timeout mymaster 180000
master故障后，故障转移超时时间，超过该值表示当前次master故障转移失败，需重新选举并转移故障。故障转移包含如下多个操作：
1，等待多个哨兵回复，选出可升级为master的slave;
2，将slave升级为master，修改哨兵配置文件记录的结点信息；
3，从节点从新master复制数据；
1.2.2，哨兵配置后属性
sentinel config-epoch mymaster 0
故障转移的版本管理，每次故障转移都需要唯一版本，防止哨兵间故障版本冲突。当哨兵执行故障转移时，将递增该版本号，并广播给其他哨兵。若哨兵间版本不一致，将使用最大版本号。
2，故障转移演示
在当前一主两从+三哨兵架构下，演示master宕机，哨兵自动故障转移情景。上面可知当前主节点是 6379. 现在停掉6379服务，模拟生产宕机，如下图：
查看6380和6381的 info replication
同理，查看哨兵日志
由上图可知， 主节点6379下线后，哨兵自动选举出6381作为主节点。
注意：
1，本机搭建案例，前面的配置IP均使用的事192...，后面哨兵选举时出现ping连接失败情况，后改为回环地址IP，则自动选举成功。
2，哨兵机制仍然存在弊端：
第一：哨兵机制可能丢失数据。
情景一：主从结构的本质是主节点写，从节点读或单纯备份。当未触发master-->slave的数据传输或备份时，master宕机，则这部分数据将丢失；
情景二：master掉线，slave被升级为新master，当旧master重新上线时，会清空自身数据，从新master复制一份全量数据，则旧master未同步数据也会丢失。
第二：哨兵机制的写操作都在master单节点，当master宕机时，整个Redis服务都不可用。
基于上述问题表明，哨兵机制更适合不需要数据分片（即数据量不大），且Redis依赖度不高的系统（即Redis宕机对系统影响不大）。对于数据量大或依赖度高的系统，Redis提供了集群架构方案，保留了哨兵架构的自主选举优点，也解决了单节点压力过大的问题，详见下章节。