Redis服务之高可用组件服务之高可用组件sentinel详解详解
主要介绍了Redis服务之高可用组件sentinel,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
前文我们了解了redis的常用数据类型相关命令的使用和说明,回顾请参考https://www.jb51.net/article/120364.htm 今天我们来聊一下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