Redis服务之高可用组件sentinel

　　前文咱们了解了redis的经常使用数据类型相关命令的使用和说明，回顾请参考http://www.javashuo.com/article/p-qvvmnuco-nq.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主从复制集群搭建

　　一、在192.168.0.41/42/43上安装redis，可使用yum安装，也可使用编译安装，redis安装请参考http://www.javashuo.com/article/p-ckvacwaq-kp.html；

　　二、配置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？

　　在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是在线；