Redis相关的问题(面试)
-
作为一名大专生的渣渣发现今年是挺难找工作的,到杭州也一月有余,面试就是老是遇到坎,不过作为一名热爱技术的人,怎么会那么容易被击垮呢??呸,说那么多没用的,说说redis吧,面试基本上都会问到的.作为渣渣2年不到经验的垃圾程序员只是笼统的整理一下,不喜勿喷哈~~(中间也会借鉴其他的博客或者发表的文章,我都会贴出出处)
-
面试官:小伙子您好,看你简历上写了你项目里面用到了Redis,你们为啥用Redis?
答:一般接触过缓存相关的小伙伴第一反应一定是Redis或者Memcached (说实在的我之前没有听过这玩意,都说了渣渣,嘿嘿) -
面试官:那你说说Redis和Memcached的区别?以及它们的使用场景?
答:(1) Redis不仅仅支持k/v类型的数据,还支持hash list set sortedset类型数据结构的存储.
(2) Redis支持数据的备份,即master-slave模式的数据备份.
(3) Redis支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用.
(4) 当物理内存用尽后,Redis可以将一些很久没用的value存储到磁盘中.Redis发现内存使用超过某个阈值,将触发swap的操作,Redis根据“swappability = age*log(size_in_memory)”计算出哪些值需要存储到磁盘中,将这些值存储到磁盘中后会将内存中的这些值删除,这种特性可以使得redis可以存储超过机器内存大小的数据,但是内存必须能够存储下所有的key,因为key不会存储到磁盘中.
(5) 它们在性能方面差别不是很大,读取方面尤其是针对批量读取性能方面memcached占据优势。当然redis也有他的优点,如持久性、支持更多的数据结构.
memcached使用的场景:通常在电子商务系统中在网站的左侧会是商品的分类,中间是商品搜索结果的列表,可以查看商品信息和商家的基本信息和相关商家的信誉度信息。
redis使用场景:(1) 会话缓存(Session Cache)
最常用的一种使用Redis的情景是会话缓存(session cache)。用Redis缓存会话比其他存储(如Memcached)的优势在于:Redis提供持久化。当维护一个不是严格要求一致性的缓存时,如果用户的购物车信息全部丢失,大部分人都会不高兴的,现在,他们还会这样吗?幸运的是,随着 Redis 这些年的改进,很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。
(2) 全页缓存(FPC)
除基本的会话token之外,Redis还提供很简便的FPC平台。回到一致性问题,即使重启了Redis实例,因为有磁盘的持久化,用户也不会看到页面加载速度的下降,这是一个极大改进,类似PHP本地FPC。再次以Magento为例,Magento提供一个插件来使用Redis作为全页缓存后端。
此外,对WordPress的用户来说,Pantheon有一个非常好的插件 wp-redis,这个插件能帮助你以最快速度加载你曾浏览过的页面。
(3) 队列
Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作,这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作,就类似于本地程序语言(如Python)对 list 的 push/pop 操作。
如果你快速的在Google中搜索“Redis queues”,你马上就能找到大量的开源项目,这些项目的目的就是利用Redis创建非常好的后端工具,以满足各种队列需求。例如,Celery有一个后台就是使用Redis作为broker,你可以从这里去查看。
(4) 排行榜/计数器
Redis在内存中对数字进行递增或递减的操作实现的非常好。集合(Set)和有序集合(Sorted Set)也使得我们在执行这些操作的时候变的非常简单,Redis只是正好提供了这两种数据结构。所以,我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”,我们只需要像下面一样执行即可:当然,这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数,你需要这样执行:
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一个很好的例子,用Ruby实现的,它的排行榜就是使用Redis来存储数据的,你可以在这里看到。
(5) 发布/订阅
最后(但肯定不是最不重要的)是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用,还可作为基于发布/订阅的脚本触发器,甚至用Redis的发布/订阅功能来建立聊天系统!(不,这是真的,你可以去核实)。
(6) 其他
但是如果是对缓存的数据格式有更多的要求,且对安全性也有很高的要求的话,建议还是使用redis,这也是redis目前正在逐渐代替memcached的根本原因。
(7) 总结
-
面试官:那么Redis支持哪几种数据类型?以及应用的场景知道吗?
回答:String、Hash、List、Set、SortedSet/ZSet。同时还有三种3种特殊的数据类型(BitMap、Geo和HyperLogLog)
(1) String 字符串
应用场景:
可完全替换memcached,存储简单k-v.
计数,存储少量热点数据,分布式锁(秒杀系统有应用)
(2) Hash 包含键值对的无序散列表
应用场景:
Redis hash 是一个string类型的field和value的映射表,就是String类型外面包了一层,hash特别适合用于存储对象。
(3) List 列表
应用场景:
取出最新n个消息(不涉及复杂排序)
比如最新1000个访客,就可以使用list,同时使用LTRIM key 0 1000,只 保存最新的1000个.
作为队列可用来走日志打印,多个端进行push,一个端进行Rpop,
(4) set 无序集合
应该场景:
一些会不重复的数据,进行交集,并集,差集等灵活操作
抖音的关注人,粉丝,可分别放在一个set中.
(5) SortedSet/ZSet 有序集合
应用场景:
sorted set 比set多了一个score的(分数),可以通过这个scored来排序,相同scored的数据按自然顺序,比如微信朋友圈就可以用sorted set 来排序,分数用时间来表示. 经典案例:一个班的同学按分数排序,就可以把分数作为scored,实现排序.当然应用远不止于此.
Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序,HashMap里放的是成员到score的映射,而跳跃表里存放的是所有的成员,排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率,并且在实现上比较简单。 -
面试官:如果有大量的key需要设置同一时间过期,一般需要注意什么?
回答:如果大量的key过期时间设置的过于集中,到过期的那个时间点,Redis可能会出现短暂的卡顿现象。严重的话会出现缓存雪崩,我们一般需要在时间上加一个随机值,使得过期时间分散一些。电商首页经常会使用定时任务刷新缓存,可能大量的数据失效时间都十分集中,如果失效时间一样,又刚好在失效的时间点大量用户涌入,就有可能造成缓存雪崩.
-
那你使用过Redis分布式锁么,它是什么回事?
回答:先拿setnx来争抢锁,抢到之后,再用expire给锁加一个过期时间防止锁忘记了释放。 -
如果在setnx之后执行expire之前进程意外crash或者要重启维护了,那会怎么样?
回答:我记得set指令有非常复杂的参数,这个应该是可以同时把setnx和expire合成一条指令来用的! -
假如Redis里面有1亿个key,其中有10w个key是以某个固定的已知的前缀开头的,如何将它们全部找出来?
回答:使用keys指令可以扫出指定模式的key列表。 -
如果这个redis正在给线上的业务提供服务,那使用keys指令会有什么问题?
回答:Redis的单线程的。keys指令会导致线程阻塞一段时间,线上服务会停顿,直到指令执行完毕,服务才能恢复。这个时候可以使用scan指令,scan指令可以无阻塞的提取出指定模式的key列表,但是会有一定的重复概率,在客户端做一次去重就可以了,但是整体所花费的时间会比直接用keys指令长。不过,增量式迭代命令也不是没有缺点的: 举个例子, 使用 SMEMBERS 命令可以返回集合键当前包含的所有元素, 但是对于 SCAN 这类增量式迭代命令来说, 因为在对键进行增量式迭代的过程中, 键可能会被修改, 所以增量式迭代命令只能对被返回的元素提供有限的保证 。
-
使用过Redis做异步队列么,你是怎么用的?
回答:一般使用list结构作为队列,rpush生产消息,lpop消费消息。当lpop没有消息的时候,要适当sleep一会再重试。 -
如果问可不可以不用sleep呢?
回答:list还有个指令叫blpop,在没有消息的时候,它会阻塞住直到消息到来。 -
如果对方接着追问能不能生产一次消费多次呢?
回答:使用pub/sub主题订阅者模式,可以实现 1:N 的消息队列。 -
如果对方继续追问 pub/su b有什么缺点?
回答:在消费者下线的情况下,生产的消息会丢失,得使用专业的消息队列如RocketMQ等. -
问Redis如何实现延时队列?
回答:使用sortedset,拿时间戳作为score,消息内容作为key调用zadd来生产消息,消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。 -
Redis是怎么持久化的?服务主从数据怎么交互的?
回答:RDB做镜像全量持久化,AOF做增量持久化。因为RDB会耗费较长时间,不够实时,在停机的时候会导致大量丢失数据,所以需要AOF来配合使用。在redis实例重启时,会使用RDB持久化文件重新构建内存,再使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。这里很好理解,把RDB理解为一整个表全量的数据,AOF理解为每次操作的日志就好了,服务器重启的时候先把表的数据全部搞进去,但是他可能不完整,你再回放一下日志,数据不就完整了嘛。不过Redis本身的机制是 AOF持久化开启且存在AOF文件时,优先加载AOF文件;AOF关闭或者AOF文件不存在时,加载RDB文件;加载AOF/RDB文件城后,Redis启动成功; AOF/RDB文件存在错误时,Redis启动失败并打印错误信息.
-
那如果突然机器掉电会怎样?
回答:取决于AOF日志sync属性的配置,如果不要求性能,在每条写指令时都sync一下磁盘,就不会丢失数据。但是在高性能的要求下每次都sync是不现实的,一般都使用定时sync,比如1s1次,这个时候最多就会丢失1s的数据。 -
对方追问RDB的原理是什么?
回答:你给出两个词汇就可以了,fork和cow。fork是指redis通过创建子进程来进行RDB操作,cow指的是copy on write,子进程创建后,父子进程共享数据段,父进程继续提供读写服务,写脏的页面数据会逐渐和子进程分离开来。 -
Pipeline有什么好处,为什么要用pipeline?
回答:可以将多次IO往返的时间缩减为一次,前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候可以发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。 -
Redis的同步机制了解么?
回答:Redis可以使用主从同步,从从同步。第一次同步时,主节点做一次bgsave,并同时将后续修改操作记录到内存buffer,待完成后将RDB文件全量同步到复制节点,复制节点接受完成后将RDB镜像加载到内存。加载完成后,再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。后续的增量数据通过AOF日志同步即可,有点类似数据库的binlog。 -
是否使用过Redis集群,集群的高可用怎么保证,集群的原理是什么?
回答:Redis Sentinal 着眼于高可用,在master宕机时会自动将slave提升为master,继续提供服务。Redis Cluster 着眼于扩展性,在单个redis内存不足时,使用Cluster进行分片存储。
参考链接
https://www.jianshu.com/p/30831f9a0fac
https://baijiahao.baidu.com/s?id=1628669085694391797&wfr=spider&for=pc
https://juejin.im/post/5db66ed9e51d452a2f15d833