redis实战--基于哨兵的高可用方案解析

前言

前面已经介绍过持久化的两种机制,以及主从复制的原理,部署。这里所谓的高可用,讲的是99.99(或者99.9%或者99%)的时间内,系统是可用的。下面我们就看下哨兵模式的相关概念。

基本介绍

功能:
哨兵是redis集群架构中非常重要的组件,主要有以下几个功能:
1.负责监控mater和slave的进程是否正常工作;如果某个实例有故障,那么哨兵会把报警消息发送给redis系统管理员。
2.如果master发送了故障,会自动转移到slave上。会通知client客户端新的master地址。

核心逻辑:
1.哨兵本身也是分布式的,哨兵是集群部署,会协同工作:比如故障发生时,需要大部分的哨兵都同意才可以做切换;
2.哨兵至少需要3个redis实例,来保证监控的健壮性;哨兵以及主从的部署架构,不能保证数据的丢失,但能保证redis集群的高可用性。

数据丢失的场景:
场景一:主备切换的过程中,可能会导致数据的丢失,因为有些数据还没复制到slave,master就死机了,这些数据就会丢失。

场景二:某个master的网段有问题(其实master还是活着,继续提高服务), 其他slave机器不能连接,这时候可能会开始新的选举,将其他的slave切换成master;这时候就会出现两个master,会导致数据的不一致(因为有些client可能还没有切换到新的,继续往老的写数据)。

解决方案:配置参数如下(意义:至少有一个slave,数据复制和同步的延迟不能超过10秒);
min-slaves-to-write 1
min-slaves-max-lag 10
也就是说所有的slave,数据同步以及符合的延迟都超过10秒钟,master就不会对外提供服务。如果不能给指定数据的slave发送数据,并且slave超过10秒没有给自己ack,master也不会对外提供写服务。

sdown和odown转换机制
sdown:主观宕机,就一个哨兵如果自己觉得一个master宕机了,超过了is-master-down-after-milliseconds指定的毫秒数之后,那么就是主观宕机

odown:客观宕机,如果quorum数量的哨兵都觉得一个master宕机了,在指定时间内,收到了quorum指定数量的其他哨兵也认为master是sdown了,那么就是客观宕机

选举算法:
哨兵集群总的哨兵实例会跟其他哨兵交换对master的监控配置信息,相互同步监控配置。
如果一个master被认为odown了,而且majority哨兵都允许了主备切换,那么某个哨兵就会执行主备切换操作,首先要选举一个slave来。

quorum和majority解析:
如果哨兵需要执行主备切换,需要quorum个数量的哨兵认为odown,然后这个哨兵还要得到majority个哨兵的授权,才可以进行切换。
如果quorum

部署步骤

配置
哨兵集群至少需要3个实例,我们分别在三台redis服务器上配置sentinel的配置文件。
创建配置文件,将文件重命名为6000.conf;将文件拷贝到/etc/sentinel/

mkdir /etc/sentinal
mkdir -p /var/sentinal/6000

port 6000
bind 192.168.0.10
dir /var/sentinal/6000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster redispwd
daemonize yes
logfile /var/log/sentinal/6000
mkdir -p /var/log/sentinal/6000

port 6000
bind 192.168.0.20
dir /var/sentinal/6000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster redispwd
daemonize yes
logfile /var/log/sentinal/6000
mkdir -p /var/log/sentinal/6000

port 6000
bind 192.168.0.30
dir /var/sentinal/6000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster redispwd
daemonize yes
logfile /var/log/sentinal/6000
mkdir -p /var/log/sentinal/6000

启动哨兵进程
redis-sentinel /etc/sentinal/6000.conf

日志里会显示出来,每个哨兵都能去监控到对应的redis master,并能够自动发现对应的slave;哨兵之间,互相会自动进行发现,用的就是之前说的pub/sub,消息发布和订阅channel消息系统和机制

查看哨兵状态:
redis-cli -h 192.168.0.10 -p 6000
sentinel master mymaster
sentinel slaves mymaster
sentinel sentinels mymaster

不足之处

目前这种基于哨兵的主从复制,一主多从架构,能够保证高可用的同时,又能够支持slave节点的水平扩展,支持读多写少的场景。 但是单个master的瓶颈也是不言而喻的,单机支持的数据量有限,如何能够支持海量的高可用服务,redis cluser就可以针对海量数据+高并发+高可用的场景。

展开阅读全文

没有更多推荐了,返回首页