在日常的 Redis 的master-slave模式下，我们一般为了实现读写分离，这样不但可以提高效率，同时在master出现故障时，我们关闭slave的只读模式，让应用去连接slave完成服务的正常使用。Sentinel可以帮助我们自动完成切换。
Sentinel是独立于Redis-server运行的一个分布式的服务。在Sentinel部署的时候，是不需要修改任何redis的配置的。Sentinel可以在运行过程中，不断的去探测redis集群中master和slave的状态，在判断出有节点故障时，可以通过Sentinel本身的API或者其他应用程序发出通知，多个Sentinel可以通过投票等方式，实现故障转移。把一个其他slave服务器升级为master。用来替换失效的master。最后通过Sentinel的服务返回给客户端一个新地址。保障应用正常运行。
这里用不同的端口来区分，就不打开太多服务器了
Redis服务搭建主从复制，其中Master为192.168.1.1，这里就不演示过程了，不会的出门左拐看Redis主从架构
Sentinel配置
在Redis源码包中有Sentinel配置文件的模板，可以复制出来修改也可以不用模板直接写
port 26379 ## 端口
daemonize yes ## 后台启动
dir /soft/redis/data ## 工作目录
logfile "/soft/redis/log/sentinel.log" ## 日志目录
sentinel monitor mymaster 192.168.1.1 6379 2 ## 监控master，当判断失效时，至少需要2个sentinel判定master失败才可以。
sentinel down-after-milliseconds mymaster 10000 ## Sentinel 判断master失效的时间，单位为毫秒。
sentinel parallel-syncs mymaster 1 # 故障转移后每次有多少个slave向slave发起复制请求。
sentinel failover-timeout mymaster 60000 #1、同一个Sentinel对同一个master两次tailover的间隔。
#########################我是分割线#########################
#以下配置是当所有Sentinel节点启动之后，自动写入的配置
//自动发现的两个slave节点
sentinel konwn-slave mymaster 192.168.1.2 6379
sentinel konwn-slave mymaster 192.168.1.3 6379
//自动发现的两个Sentinel节点
sentinel known-sentinel mymaster 192.168.1.2 26379 814149a8600fede18177b7cc0611a86eab61699c
sentinel known-sentinel mymaster 192.168.1.3 26379 9ec521108aacc04347b0b5aa36d32680f394dc4b
sentinel current-epoch 0 #当前配置信息版本，如果配置文件发生变化，版本信息也会变化。启动Sentinel
## 第一种启动方式（推荐）
[root@Master ~]# /soft/redis/bin/redis-sentinel /soft/redis/conf/sentlnel.conf
## 第二种启动方式
[root@Master ~]# /soft/redis/bin/redis-server /soft/redis/conf/sentlnel.conf --sentinel三台服务器都配置启动后，查看Sentinel配置文件，多出来发现其他角色信息。
1）一般每个Sentinel服务器都需要 每间隔 10s 一次的频率向一直的master和slaves 发送INFO命令。通过这个任务可以发现Slaves节点是否增加或者删除。当一个Master被标记为下线时，会修改为每秒发送一次命令。
2）每个Sentinel以每秒钟一次的频率向已知的master、slaves以及其他的Sentinel实例发送一个 ping 命令。如果 ping 命令无法得到一个有效的回复，并且距离上次响应时间超过down-after-milliseconds 选项设定的值，则会被标记为主观下线
3）每个Sentinel会以每2秒一次的频率，通过发布订阅的功能，向其他被它监视的所有主服务器和从服务器的Sentinel发送hello包，信息中包含了Sentinel的IP地址、端口号和运行ID（runid）
1.执行任务1，发送 INFO 命令，通过解析 INFO 命令的返回值，发现Slave的节点，并对Slave进行监控。这也就是为什么在Sentinel配置的时候，不需要配置Redis-Server从节点的信息的原因。
2.信息拓扑 INFO 命令查看到Redis-Server拓扑发生主从切换，或者增加删除节点时，都可以实时更新到Sentinel的监控列表。
1.执行任务3 每个Sentinel都订阅了被它监视的所有主服务器和从服务器的Sentinel:hello频道，查找之前未出现过的Sentinel（looking for unknown sentinels）。当一个Sentinel发现一个新的Sentinel时，它会将新的Sentinel添加到一个列表中，并与该节点创建连接，这个列表保存了Sentinel已知的，监视同一个主服务器的所有其他Sentinel。
2.Sentinel发送的信息还包括完整的主服务器的当前配置。如果一个Sentinel包含的主服务器的配置比Sentinel发送的配置要旧，那么这个Sentinel会立即更新配置。
3.Sentinel节点之间的交换主节点状态信息，会作为后边客观下线以及领导者选举的依据。
1.通过以上的任务，我们可以发现新的Redis-Server节点，也可以获取最新信息，以及获取Sentinel的节点信息。
2.通过定时任务2，每秒钟向Redis-Server的Master以及Slave节点。以及Sentinel的其他节点发送 ping 命令。
3.通过与每个节点的心跳检测，实现对每个节点的监控（Redis以及Sentinel），这个任务是节点判定失败的重要依据。
4.例如Sentinel-1发现某个节点相应超过down-after-milliseconds时间段没有有效回复，Sentinel节点会判定为失败和标记下线。这个行为叫做主观下线。
5.当Sentinel主观下线的节点时redis的master的时候，Sentinel会通过sentinel is master-down-by-addr 命令向其他的Sentinel节点询问对主节点的判断。当超过设定的票数时（我们三个节点，设定票数2，忘记的回顾一下前边配置），该节点会做出客观下线的决定。客观下线一旦判定之后，后边大家就都知道了，就开始切换了。
原文：https://www.cnblogs.com/songguoyou/p/11884192.html