Sentinel是一个分布式系统，我们可以在一个架构中运行多个sentinel，这些sentinel进程使用流言协议（gossipprotocols）来接收关于 Master是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个 Slave 作为新的 Master。每个sentinel进程会向其他sentinel进程、master、slave定时发送消息，以确保对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，英文名称：Subjective Down，简称 SDOWN。
前文我们了解了redis的常用数据类型相关命令的使用和说明，回顾请参考https://www.cnblogs.com/qiuhom-1874/p/13419690.html；今天我们来聊一下redis的高可用组件sentinel；首先来回顾下redis的主从同步，主从同步最主要的作用是让master的数据在其他服务器上实时存在副本，起到了备份的效果；对于redis的读写来说，主从架构能够让读的请求分散到多个从服务器上，从而降低了单台redis读请求的io压力，同时也提高了redis读请求的并发能力；通常为了数据的一致性，从服务器一旦成为某一台redis的slave，那么从服务器上之前有的数据会被清空，然后把master发送过来的数据应用到内存，从而实现和master数据一致；除此之外slave通常会是只读属性，也就说slave端只能执行读操作，写操作会被拒绝，所以写请求始终是由master来完成；那么问题来了，对于这种主从复制架构的环境中，如果master宕机了，master宕机意味着整个系统将不能够写数据到redis,很显然这种情况我们应该及时解决；怎么解决呢？有没有这样的一组件帮我们对master做实时的监控，一旦发现master宕机就提升一个slave当选新的master，如果原master还有其他slave，将其他slave都从属于新的master；除此之外它还应该让系统在发生切换master时触发报警通知，让管理员尽快把坏掉的master修复上线；对，sentinel就有我们上述的这些功能，它能够监控主从同步集群中的master节点，在master发生宕机后能够自动故障转移，将提升一台slave作为新的master，然后通知管理员；
Sentinel是一个分布式系统，我们可以在一个架构中运行多个sentinel，这些sentinel进程使用流言协议（gossipprotocols）来接收关于 Master是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个 Slave 作为新的 Master。每个sentinel进程会向其他sentinel进程、master、slave定时发送消息，以确保对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，英文名称：Subjective Down，简称 SDOWN。有主观宕机，肯定就有客观宕机。当多个sentinel进程中多数的sentinel进程在对 Master 做出 SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的 Master Server 下线判断，这种方式就是“客观宕机”，英文名称是：Objectively Down， 简称 ODOWN。通过一定的 vote 算法，从剩下的 slave 从服务器节点中，选一台提升为 Master 服务器节点，然后自动修改相关配置，并开启故障转移（failover）。
配置使用sentinel
环境说明
| 角色 | ip地址 | 端口 |
| master | 192.168.0.41 | 6379 |
| slave01 | 192.168.0.42 | 6379 |
| slave02 | 192.168.0.43 | 6379 |
| sentinel01 | 192.168.0.41 | 26379 |
| sentinel02 | 192.168.0.42 | 26379 |
| sentinel03 | 192.168.0.43 | 26379 |
架构图
提示：从上面的架构图可以知道，首先我们必须要有一个主从架构的集群，然后在部署sentinel 来对主从同步集群做监控；
redis主从复制集群搭建
1、在192.168.0.41/42/43上安装redis，可以使用yum安装，也可以使用编译安装，redis安装请参考https://www.cnblogs.com/qiuhom-1874/p/13378138.html；
2、配置192.168.0.41/42/43上的redis监听在非本机127.0.0.1上并配置42/43上的redis从属于192.168.0.41
master
slave01
slave02
提示：redis支持在线修改配置，保存配置到配置文件；SLAVEOF 指令用于指定redismaster的ip地址和端口，表示把该redis配置成对应master的slave角色；CONFIG REWRITE是把我们的配置保存到配置文件；
在master上查看是否有两个从节点连接到master
验证：在master上写数据，看看是否能够及时同步到两个slave上？
提示：可以看到在主库上写数据，从库上能够及时的同步主库上的数据；到此redis的主从集群就搭建完毕了；
配置sentinel，让其监控master
提示：三个sentinel的配置都是一样的，这里需要明确指定监控主从同步集群的master的ip地址和端口，以及有效法定票数，有效法定票数指的是至少有多少个sentinel主观认为master down了，然后才触发选举新master操作；通常在这种流言协议中，一般都是大于集群半数，如果是3台sentinel，至少要2台主观认为master宕机，才开始触发选举新master；如果是5台，那至少要3台；如果master配置的有认证密码，我们还需要在sentinel中指定认证密码；
sentinel配置文件说明
bind：该指令和redis配置文件中的bind是同样的用法，用于指定sentinel的监听地址；默认不指定，监听本机所有可用地址；
protected-mode：指定是否开启保护模式；
port：用于指定sentinel的监听端口；默认是26379
daemonize：用于指定sentinel是否运行为守护进程，yes表示运行为后台守护进程；no表示不运行为守护进程，直接在前台运行；
pidfile：指定pid文件路径；
logfile：指定日志文件路径；
dir：指定sentinel的工作路径；
sentinel monitor
sentinel auth-pass
sentinel down-after-milliseconds
sentinel parallel-syncs
sentinel failover-timeout
sentinel notification-script
了解了sentinel的配置文件，接下我们把3台sentinel都启动起来
master
slave01
slave02
提示：从上面的信息可以看到3个sentinel都监空master的ip地址和端口，他们3个的配置文件都是一样的；
查看sentinel日志
提示：从上面的日志信息可以了解到sentinel监控的master是192.168.0.41：6379；并且有两个slave分别是192.168.0.42：6379和192.168.0.43：6379；
查看sentinel状态
提示：它提示我们开启了保护模式；
关闭保护模式
重启sentinel，再次查看sentinel状态
[root@master ~]# systemctl restart redis-sentinel.service [root@master ~]# ss -tnlState Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 511 *:26379 *:* LISTEN 0 511 *:6379 *:* LISTEN 0 128 *:22 *:* LISTEN 0 100 127.0.0.1:25 *:* LISTEN 0 511 :::26379 :::* LISTEN 0 128 :::22 :::* LISTEN 0 100 ::1:25 :::* [root@master ~]# redis-cli -h 192.168.0.41 -p 26379 192.168.0.41:26379> info sentinel# Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0sentinel_simulate_failure_flags:0master0:name=mymaster,status=ok,address=192.168.0.41:6379,slaves=2,sentinels=3192.168.0.41:26379> info clients# Clientsconnected_clients:3client_longest_output_list:0client_biggest_input_buf:0blocked_clients:0192.168.0.41:26379> CLIENT LISTid=2 addr=192.168.0.42:59048 fd=14 name=sentinel-f60b324b-cmd age=38 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=pingid=3 addr=192.168.0.43:37480 fd=15 name=sentinel-eada229c-cmd age=38 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=publishid=4 addr=192.168.0.41:36706 fd=16 name= age=32 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client192.168.0.41:26379>
提示：从上面的状态信息可以看到当前我们sentinel监控的master是出于正常ok状态，有两个slave和3个sentinel；对于192.168.0.41：26379目前有3个客户端连接，二个是sentinel，一个本机；到此3台sentinel搭建启动完成；
验证：把master宕机，看看sentinel是否将在两个从节点选举一个为新master？是否将另外一个slave重新指向新master？
在slave02上查看主从同步信息
提示：第一次查看只是告诉我们master宕机了，第二次查看就告诉我们当前节点为master，并且拥有一个slave节点；
在192.168.0.43上查看主从信息，看看是否指向新的master？
提示：在slave02上看主从同步信息，可以看到slave02已经从属新master了；
查看故障转移时 sentinel日志
提示：从上面的日志信息可以了解到，在从sdown到odown后，就会触发vote算法开始选举leader；然后将原master降级为slave，然后将选举出来的leader原salve属性去除（slaveof no one）;然后提示新master，然后将剩下的slave重新配置新master为主；最后是切换master，开始新的监控；
查看故障 转移后的 s redis 配置文件
提示：故障转移后 redis.conf 中的 slaveof 行的 master IP 会被修改，sentinel.conf 中的 sentinel monitor IP 会被修改。同时在sentinel配置文件的末尾还会有添加known-slave和known-sentinel等信息；
修复旧master 让其重新上线
提示：把原master启动后，它自动就成为了新主的slave；这主要是因为sentinel在故障转移时把其配置文件中的slaveof 修改成新的master地址了；
在新master上查看主从同步信息
提示：在没有恢复原master时，在新master上查看主从同步信息，只能看到一个salve，启动原master后，在看就有两个slave是在线；
Redis服务之高可用组件sentinel文章转载：http://www.shaoqun.com/a/463910.html