Sentinel(哨兵)，顾名思义就是站岗放哨的，是redis提供的高可用解决方案，它是对主从模式的优化升级，在主从模式下，如果主库发生宕机，需要人工介入将某个从节点提升为主库，同时需要修改应用配置的主节点地址，而在Sentinel模式下，每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间内未得到回应，会对节点做下线标识，如果被标识的是主节点，它还会与其他Sentinel节点进行协商，当多数派都认为主节点不可达时，它们会选举出一个Sentinel节点来完成故障转移的工作，同时会通知应用方主节点已经发生转移。下面我们就来搭建一个Sentinel集群。
从节点配置文件和主节点配置文件的主要区别是将6377改成从节点对应的端口号，本次实验两个从节点的端口号分别为6378和6379。同时配置需要同步的主节点的IP和端口。
确认主从是否生效
故障转移的大体步骤如下：
安装部署
环境准备
在这里我们使用的是Redis 4.0.10，在一台服务器上启动三个server来模拟一主两从的架构，redis的安装过程这里就不在演示了，可以参考文章【redis】部署及参数详解（吐血整理,建议收藏）。
部署过程
1. 启动主节点
修改配置文件/usr/local/redis/etc/redis_6377.conf，主要注意以下几个参数
port 6377daemonize yeslogfile "/redis_data/log/redis_6377.log"dir "/redis_data/data/6377"dbfilename "dump_6377.rdb"执行启动命令
redis-server /usr/local/redis/etc/redis_6377.conf通过redis客户端连接测试
redis-cli -h 127.0.0.1 -p 6377127.0.0.1:6377> pingPONG2. 启动从节点
从节点配置文件和主节点配置文件的主要区别是将6377改成从节点对应的端口号，本次实验两个从节点的端口号分别为6378和6379。同时配置需要同步的主节点的IP和端口。
slaveof 127.0.0.1 6377启动从节点
redis-server /usr/local/redis/etc/redis_6378.confredis-server /usr/local/redis/etc/redis_6379.conf
确认主从是否生效
[redis@localhost etc]$ redis-cli -h 127.0.0.1 -p 6377 info replication# Replicationrole:masterconnected_slaves:2slave0:ip=127.0.0.1,port=6378,state=online,offset=308,lag=0slave1:ip=127.0.0.1,port=6379,state=online,offset=308,lag=13. 启动Sentinel节点 Sentinel节点至少3个且奇数，这样才能在协议中形成多数派。配置Sentinel节点配置文件/usr/local/redis/sentinel-26377.conf，主要注意以下参数
port 26377dir "/redis_data/data/26377"logfile "/redis_data/log/redis-26377.log"#配置主节点的IP和端口，2代表主节点判断失败至少需要2个Sentinel节点同意，一般设置为Sentinel节点数的一半加1.sentinel monitor mymaster 127.0.0.1 6377 2#30秒ping不通主节点的信息，主观认为master宕机sentinel down-after-milliseconds mymaster 30000#故障转移时从节点同时向新主发起复制请求的数量，1代表从节点会轮询发起复制。sentinel parallel-syncs mymaster 1#故障转移开始，180秒内没有完成，则认为转移失败sentinel failover-timeout mymaster 180000启动Sentinel节点
redis-sentinel sentinel-26377.confredis-sentinel sentinel-26378.confredis-sentinel sentinel-26379.conf4. 通过Sentinel节点查看哨兵是否生效
[redis@localhost redis]$ redis-cli -h 127.0.0.1 -p 26377 info Sentinel# Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0sentinel_simulate_failure_flags:0master0:name=mymaster,status=ok,address=127.0.0.1:6377,slaves=2,sentinels=3至此，Sentinel模式的redis集群搭建就完成了。
故障转移
模拟主库宕机，通过kill命令杀死主库，查看故障转移情况：
127.0.0.1:26377> info sentinel# Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0sentinel_simulate_failure_flags:0master0:name=mymaster,status=ok,address=127.0.0.1:6378,slaves=2,sentinels=3可以看到master改为127.0.0.1:6378了。
故障转移的大体步骤如下：
每个Sentinel节点每隔1秒对主、从、其他Sentinel阶段发送ping探测，超过down-after-milliseconds未返回响应，则判断该节点主观下线。
Sentinel节点向其他Sentinel节点询问对于异常节点的判断，当达到 quorum个sentinel节点都认为被主观下线的节点异常时，则对该节点做客观下线。
在sentinel节点中通过Raft算法选举出一个leader来完成故障转移。
当出现故障的节点是主节点时，sentinel leader会根据优先级、复制偏移量、runid等在从节点中选出一个作为主节点，执行slaveof no one命令。
leader向其他从节点发送指令，让他们成为新主的从节点，并将原来的主节点更新为从节点，当旧主恢复后去复制新主的数据。
复制完成后，发布主节点的切换消息。