redis哨兵集群架构的核心知识及原理

文章目录

    • 一、什么是redis高可用架构?
    • 二、如何实现redis主备切换的高可用性?
      • 1.哨兵的作用
      • 2.哨兵的核心知识
      • 3.为什么redis哨兵集群只有两个节点无法正常工作?
    • 三、redis哨兵主备切换的数据丢失问题:异步复制、集群脑裂
      • 1.异步复制
      • 2.集群脑裂问题
      • 3.如何解决异步复制和脑裂导致的数据丢失?
    • 四、redis哨兵的多个核心底层原理的深入解析(包含slave选举算法)
      • 1.sdown和odown转换机制
      • 2.哨兵集群的自动发现机制
      • 3.slave到master的选举算法
    • 总结 怎么保证redis是高并发以及高可用的?
      • 1.实现redis的高并发
      • 2.实现redis的高可用


一、什么是redis高可用架构?

redis高可用架构也叫做故障转移,或主备切换。redis哨兵集群架构的核心知识及原理_第1张图片

二、如何实现redis主备切换的高可用性?

通过哨兵 (sentinel)
哨兵是redis集群中的重要组件

1.哨兵的作用

集群监控:负责监控redis master和slave进程是否正常工作
消息通知:如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员
故障转移:如果master node挂掉了,会自动转移到slave node上

2.哨兵的核心知识

1)哨兵至少需要3个实例,来保证自己的健壮性
2)哨兵+redis主从的这种架构不能保证数据的零丢失,只能保证redis集群的高可用

3.为什么redis哨兵集群只有两个节点无法正常工作?

这里有两个概念:quorum和marority;
quorum 也就是认为机器故障的个数,比如有5台机器,quorum设置为3 那就是 如果有3个节点认为master宕机了,sentinal集群就会认为master宕机了。
majoritory 代表允许故障转移的机器个数 例如2的majority=2,3的majority=2,4的majority=2,5的majority=3
而对于两个节点的redis集群来说,他们的quorum可以设置为1,也就是s1和s2中只要有一个节点认为master宕机了就可以进行故障转移,但是此时的majority是2,也就是至少要有2个系节点才允许故障转移,这时候因为只有一个s1节点,就无法进行故障转移 。

正确的哨兵模式:3节点哨兵集群

redis哨兵集群架构的核心知识及原理_第2张图片
经典的3节点哨兵集群,我们配置quorum = 2,3个节点的majority也是2,如果M1所在的机器宕机了,那么三个哨兵还剩下2个,S2和S3可以一致认为mater宕机,然后选举一个来执行故障转移
同时majority也是2,这个2个哨兵可以允许执行故障转移的。

三、redis哨兵主备切换的数据丢失问题:异步复制、集群脑裂

1.异步复制

异步复制导致的数据丢失问题 即master node挂掉后,slave node 就成了master node,那些内存中还没来得及的复制的数据就丢失了redis哨兵集群架构的核心知识及原理_第3张图片

2.集群脑裂问题

即master主节点,出现了异常性的,有相同数据,相同工作的,两个节点, 脑裂时虽然某个slave被切换成了master,但是client还没来得及切换到新的master,此时如果恢复,旧的master会被作为一个slave挂载到新的master上去,自己的数据就会被清空,重新从新的mater复制数据,导致数据丢失

3.如何解决异步复制和脑裂导致的数据丢失?

通过两个配置: min-slave-to-write 1 ; min-slave-max-lag 10
即要求至少要有一个slave,数据复制和同步的延迟不能超过10s。如果说一旦所有的slave,数据复制和同步的延迟都超过了10s,那么这个时候,master就不会接收任何请求了

四、redis哨兵的多个核心底层原理的深入解析(包含slave选举算法)

1.sdown和odown转换机制

sdown是主观宕机
达成sdown的条件:如果一个哨兵ping一个master,超过了is-down-after-millisecond指定的毫秒数,就主观认为master宕机了
odown是客观宕机
sdown到odown的转换条件:如果一个哨兵在指定的时间内,收到了quorum指定数量的其他哨兵也认为那个master是sdown了,那么就认为是odown了,客观认为master宕机

2.哨兵集群的自动发现机制

哨兵之间的互相发现是通过redis的pub/sub机制实现,每个哨兵都会往_sentinal_:hello 这个channel发送消息并监听这个channel,这个时候所有其他哨兵都可以消费到这个消息,并感知到其他哨兵的存在。
哨兵之间会交换对master的监控配置,互相进行监控配置的同步

3.slave到master的选举算法

如果一个master被认为是odown了,同时majority哨兵也允许了主备切换,那么某个哨兵就会执行主备切换操作,而选举会考虑slave的一些信息,
1)跟master断开连接的时长 【如果时长过长也会被认为不适合被选举成master】
2)slave的优先级 (slave priority越低,优先级就越高)
3)复制offset (哪个slave复制了越多的数据,offset就越靠后,优先级就越高)
4)run id

总结 怎么保证redis是高并发以及高可用的?

1.实现redis的高并发

主从架构,一主多从,单主用来写入数据单机几万的QPS,多从用来查询数据,多个从实例可以提供每秒10万的QPS。
如果redis实现高并发的同时,还需要容纳大量的数据,如果你的缓存要容纳的数据量很大,达到了几十g,或者几百g,那就要redis集群,而且用redis集群之后,可以提供每秒几十万的读写并发

2.实现redis的高可用

如果是主从架构部署,其实就是加上哨兵就可以实现任何一个实例宕机,自动进行主备切换

你可能感兴趣的:(分布式缓存,redis,java,分布式,缓存,spring,cloud)