Redis服务之高可用组件sentinel
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 <master-name> <ip> <redis-port> <quorum>：用于指定监控master节点的ip地址和端口以及有效法定票数；其中<master-name>是给监控的master一个名称，可以随便写，起标识的作用；<quorum>表示sentinel集群的quorum机制，即至少有quorum个sentinel节点同时判定主节点故障时，才认为其真的故障；
sentinel auth-pass <master-name> <password>：指定master认证密码；通常都需要设置密码，并且master的密码和slave的密码应该是一样；
sentinel down-after-milliseconds <master-name> <milliseconds>：配置监控到指定的集群的主节点异常状态持续多久方才将标记为“故障”；
sentinel parallel-syncs <master-name> <numslaves>：指在failover过程中，能够被sentinel并行配置的从节点的数量；
sentinel failover-timeout <master-name> <milliseconds>：sentinel必须在此指定的时长内完成故障转移操作，否则，将视为故障转移操作失败；
sentinel notification-script <master-name> <script-path>：通知脚本，此脚本被自动传递多个参数；
了解了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 -tnl State 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 # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=192.168.0.41:6379,slaves=2,sentinels=3 192.168.0.41:26379> info clients # Clients connected_clients:3 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 192.168.0.41:26379> CLIENT LIST id=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=ping id=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=publish id=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=client 192.168.0.41:26379>
提示：从上面的状态信息可以看到当前sentinel监控的master是出于正常ok状态，有两个slave和3个sentinel；对于192.168.0.41：26379目前有3个客户端连接，二个是sentinel，一个本机；到此3台sentinel搭建启动完成；
验证：把master宕机，看看sentinel是否将在两个从节点选举一个为新master？是否将另外一个slave重新指向新master？
在slave01上查看主从同步信息
提示：第一次查看只是告诉我们master宕机了，第二次查看就告诉我们当前节点为master，并且拥有一个slave节点，这说明已经完成了故障转移，slave01已经被提升为新的master了；
在192.168.0.43上查看主从信息，看看是否指向新的master？
提示：在slave02上看主从同步信息，可以看到slave02已经从属新master了；
查看故障转移时 sentinel日志
提示：从上面的日志信息可以了解到，在从sdown到odown后，就会触发vote算法开始选举leader；然后将原master降级为slave，然后将选举出来的leader原salve属性去除（slaveof no one）;然后提升新master，然后将剩下的slave重新配置新master为主；最后是切换master，开始新的监控；
查看故障 转移后的 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是在线；
