《【面试突击】— Redis篇》--Redis Cluster及缓存使用和架构设计的常见问题

能坚持别人不能坚持的,才能拥有别人未曾拥有的。
关注编程大道公众号,让我们一同坚持心中所想,一起成长!!

《【面试突击】— Redis篇》--Redis Cluster及缓存使用和架构设计的常见问题

在这个系列里,我会整理一些面试题与大家分享,帮助年后和我一样想要在金三银四准备跳槽的同学。
我们一起巩固、突击面试官常问的一些面试题,加油!!

《【面试突击】— Redis篇》--Redis数据类型?适用于哪些场景?

《【面试突击】— Redis篇》--Redis的线程模型了解吗?为啥单线程效率还这么高?

《【面试突击】— Redis篇》-- Redis的主从复制?哨兵机制?

《【面试突击】— Redis篇》-- Redis哨兵原理及持久化机制

说说Redis cluster

在redis cluster集群架构中,可以由N个redis master node组成,每个master node都可以挂载多个slave node。
可以自动将数据进行分片,每个master上放一部分数据;
还提供内置的高可用支持,部分master不可用时,还是可以继续工作的,因为每个master都有salve节点,那么如果mater挂掉,redis cluster这套机制,就会自动将某个slave切换成master;
支持读写分离:对于每个master来说,都负责写请求,写就写到master,然后读就从mater对应的slave去读;

总结:redis cluster(多master + 读写分离 + 高可用)

我们只要基于redis cluster去搭建redis集群即可,不需要再手工去搭建replication复制+主从架构+读写分离+哨兵集群+高可用,不需要这样去搭了。

redis cluster 和 redis replication + sentinal的使用场景是什么

redis replication + Sentinal:redis的一主多从,读写分离+哨兵机制

如果数据量很少,主要是承载高并发高性能的场景,比如缓存一般就几个G的话,单机足够了。那就搭建主从复制的架构(redis replication),一个mater,多个slave,要几个slave跟你要求的读吞吐量有关系,然后自己搭建一个sentinal集群,去保证redis主从架构的高可用性,就可以了。

而redis cluster 主要是针对海量数据+高并发+高可用的场景,如果是海量数据,如果你的数据量很大,那么建议就用redis cluster,所有master的容量总和就是redis cluster可缓存的数据容量。

redis cluster中是如何实现数据分布的?这种方式有什么优点?

redis cluster有固定的16384个hash slot(哈希槽),对每个key计算CRC16值,然后对16384取模,可以获取key对应的hash slot。

redis cluster中每个master都会持有部分slot(槽),比如有3个master,那么可能每个master持有5000多个hash slot。

hash slot让node的增加和移除很简单,增加一个master,就将其他master的hash slot移动部分过去,减少一个master,就将它的hash slot移动到其他master上去。每次增加或减少master节点都是对16384取模,而不是根据master数量,这样原本在老的master上的数据不会因master的新增或减少而找不到。并且增加或减少master时redis cluster移动hash slot的成本是非常低的。

redis cluster节点间通信是什么机制?

redis cluster节点间采取gossip协议进行通信,所有节点都持有一份元数据,不同的节点如果出现了元数据的变更之后U不断地i将元数据发送给其他节点让其他节点进行数据变更。

节点互相之间不断通信,保持整个集群所有节点的数据是完整的。
主要交换故障信息、节点的增加和移除、hash slot信息等。

这种机制的好处在于,元数据的更新比较分散,不是集中在一个地方,更新请求会陆陆续续,打到所有节点上去更新,有一定的延时,降低了压力;

缺点,元数据更新有延时,可能导致集群的一些操作会有一些滞后。

如果现在有个读超高并发的系统,用Redis来抗住大部分读请求,你会怎么设计?

首先,如果是读高并发的话,先看读并发的数量级是多少,因为redis单机的读QPS在万级,每秒几万没问题,使用一主多从+哨兵集群的缓存架构来承载每秒10W+的读并发,主从复制,读写分离。使用哨兵集群主要是提高缓存架构的可用性,解决单点故障问题。主库负责写,多个从库负责读,支持水平扩容,根据读请求的QPS来决定加多少个redis从实例。如果读并发继续增加的话,只需要增加redis从实例就行了。

如果系统现在的业务量上升了,需要缓存1T+的数据,你怎么做?

因为Redis支撑海量数据的瓶颈在于单机容量,所以这个时候我会选择redis cluster模式,每个主节点存一部分数据,假设一个master存32G,那只需要n*32G>=1T,n个这样的master节点就可以支持1T+的海量数据的存储了。

Redis单主的瓶颈不在于读写的并发,而在于内存容量,即使是一主多从也是不能解决该问题,因为一主多从架构下,多个slave的数据和master的完全一样。假如master是10G那slave也只能存10G数据。所以数据量受单主的影响。
而这个时候又需要缓存海量数据,那就必须得有多主了,并且多个主保存的数据还不能一样。redis官方给出的 redis cluster 模式完美的解决了这个问题。

了解什么是redis的雪崩和穿透吗?如何应对?

其实这是问到缓存必问的,因为缓存雪崩和穿透,那是缓存最大的两个问题,要么不出现,一旦出现就是致命性的问题。所以面试官一定会问你。

我先描述下如何出现的缓存雪崩吧。

举个例子,假设每天高峰期的时候系统每秒请求是5000次,缓存在高峰期可以分担每秒4000次请求,另外1000次请求落到数据库(假设数据库每秒可承担2000次请求)。如果此时过来5000请求,但是redis因为某些原因挂掉了,缓存整个就不能用了,那么这5000个请求就全部落到数据库。显然数据库扛不住,直接崩溃。此时,如果没用什么特别的方案来处理这个故障,只是很着急的重启数据库,结果因为缓存还没数据,立马数据库又被新的流量给打死了。这就是缓存雪崩。

对于缓存雪崩主要分为事前事中事后,
事前:如果缓存不可用是因为缓存中的大部分数据集中失效,我们可以对缓存的失效时间加上一个随机值,使失效时间分散一点,尽量避免集中失效。另外如果是因为别的原因redis宕机导致缓存不可用,这时候我们就需要提前做好Redis高可用的架构,如主从+哨兵或redis cluster,来避免Redis出现故障时整个缓存不可用,全盘崩溃。

事中:可以将一小部分数据同样缓存到本地ehcache(本地缓存组件)缓存,另外加上hystrix限流&降级组件,避免MySQL被打死。

事后:如果真的发生雪崩,我们还可以用redis的RDB或AOF重启redis快速从磁盘加载缓存数据。这就需要我们提前打开Redis持久化机制,在雪崩发生的事后快速恢复缓存数据,一旦重启从磁盘中恢复数据到内存。

另外一个问题,缓存穿透,一般是黑客恶意攻击,或是自己系统出bug。例如黑客恶意伪造请求,这些请求都是数据库根本查不到的,所以缓存中也没用,那这些大量的恶意请求都会落到数据库去查询,数据库不就挂了吗?

解决办法就是
1、只要从数据库没查到,就写入一个空值到缓存里去。
2、使用布隆过滤器对请求的key进行一层过滤,过滤掉系统认为不存在不合法的key。

说一说redis的过期策略吧

可以参考之前的这篇文章,什么?我往Redis里写的数据怎么没了?

谈谈缓存+数据库双写不一致问题

可以参考之前的这篇文章,高并发场景下缓存+数据库双写不一致问题分析与解决方案设计


《【面试突击】—Redis篇》就要结束了,暂时就整理这么多,如果你还有更多的可以告诉我来补充哦

本系列文章在于面试突击,不是教程,要是细挖能讲好多,而面试你只需要把这个原理说出来就行了,如果边讲边画图那就更好了。

该系列文章在于快速突击,快速拾遗,温习。

posted @ 2020-01-19 14:41  为何不是梦  阅读(...)  评论(...编辑  收藏