精心整理了20道Redis经典面试题(珍藏版)

有关Redis之前有单独写过几篇文章
Redis缓存穿透、击穿、雪崩,数据库与缓存一致性
谈谈Redis五种数据结构及真实应用场景
一文让你明白Redis持久化(RDB、AOF)
怎么实现Redis的高可用?(主从、哨兵、集群)
之所以单独写,是因为这几块内容比较大,而且也很重要,所以想写的详细点、深入点,让大家在理解的基础上记住它们,这让就不容易忘记。
所以有关以上相关的面试题就不再单独整理了,具体可以看相关文章。

  • redis是什么?
  • Redis为什么这么快?
  • 为什么Redis 6.0之后改多线程呢?
  • 你了解Redis的过期策略吗?
  • 聊聊Redis内存淘汰策略?
  • Redis事务机制是怎样的?
  • 说说Redis哈希槽的概念?
  • 为什么Redis Cluster会设计成16384个槽呢?
  • Redis在集群中查找key的时候,是怎么定位到具体节点的?
  • Redis底层使用的什么协议?
  • Redis的Hash冲突怎么办?
  • Redis相比memcached有哪些优势?
  • 有哪些办法可以降低 Redis 的内存使用情况呢?
  • Redis中获取海量数据的正确操作方式?
  • 如何使用Redis的性能更高?
  • 如何解决Redis的并发竞争Key问题?
  • 使用过Redis做异步队列么,你是怎么用的?
  • 用Redis做过延时队列吗? 具体应该怎么实现?
  • 使用Redis统计网站的UV,应该怎么做?
  • 什么是热Key问题,如何解决热key问题?
1、redis是什么 Redis是C语言开发的一个开源的高性能键值对(key-value)的内存数据库,它是一种NoSQL(泛指非关系型)的数据库。
与MySQL数据库不同的是,Redis的数据是存在内存中的。它的读写速度非常快,每秒支持并发10W QPS。因此Redis被广泛应用于缓存,另外,Redis也经常用来做分布式锁,也可以用来做消息中间件等。
【精心整理了20道Redis经典面试题(珍藏版)】除此之外,Redis还支持事务、持久化、LUA脚本、多种集群方案。
2、Redis为什么这么快? 1) 完全基于内存存储实现
完全基于内存,绝大部分请求是纯粹的内存操作,非常快速。数据存在内存中,类似于HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1);
2) 合理的数据编码
Redis 支持多种数据数据类型,每种基本类型可能对多种数据编码。什么时候,使用什么样数据类型,使用什么样编码,是redis设计者总结优化的结果。
3) 单线程模型
Redis是单线程模型的,而单线程避免了CPU不必要的上下文切换和竞争锁的消耗。也正因为是单线程,如果某个命令执行过长(如keys,hgetall命令),会造成排队阻塞。
Redis 6.0 引入了多线程提速,它的执行命令操作内存的仍然是个单线程的。
4) 合理的线程模型
使用多路I/O复用模型,非阻塞IO;
多路I/O复用技术可以让单个线程高效的处理多个连接请求,而Redis使用epoll作为I/O多路复用技术的实现。并且,Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件,不在网络I/O上浪费过多的时间。
3、为什么Redis 6.0 之后改多线程呢? Redis6.0之前,Redis在处理客户端的请求时,包括读socket、解析、执行、写socket等都由一个顺序串行的主线程处理,这就是所谓的“单线程”。
redis使用多线程并非是完全摒弃单线程,redis还是使用单线程模型来处理客户端的请求,只是使用多线程来处理数据的读写和协议解析,执行命令还是使用单线程。
这样做的目的是因为redis的性能瓶颈在于网络IO而非CPU,使用多线程能提升IO读写的效率,从而整体提高redis的性能。
4、你了解Redis的过期策略吗? 我们在set key的时候,可以给它设置一个过期时间,比如expire key 60。指定这key 60s后过期,60s后redis是如何处理的?我们先来介绍几种过期策略:
定时过期
每个设置过期时间的key都需要创建一个定时器,到过期时间就会立即对key进行清除。该策略可以立即清除过期的数据,对内存很友好;但是会占用大量的CPU资源去处理过期的数据,从而影响缓存的响应时间和吞吐量。
惰性过期
只有当访问一个key时,才会判断该key是否已过期,过期则清除。该策略可以最大化地节省CPU资源,却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问,从而不会被清除,占用大量内存。
定期过期
每隔一定的时间,会扫描一定数量的数据库的expires字典中一定数量的key,并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
Redis中同时使用了惰性过期定期过期两种过期策略。
假设Redis当前存放30万个key,并且都设置了过期时间,如果你每隔100ms就去检查这全部的key,CPU负载会特别高,最后可能会挂掉。
因此,redis采取的是定期过期,每隔100ms就随机抽取一定数量的key来检查和删除的。
但是呢,最后可能会有很多已经过期的key没被删除。这时候,redis采用惰性删除。在你获取某个key的时候,redis会检查一下,这个key如果设置了过期时间并且已经过期了,此时就会删除。
但是呢,如果定期删除漏掉了很多过期的key,然后也没走惰性删除。就会有很多过期key积在内存中,直接会导致内存爆的。或者有些时候,业务量大起来了,redis的key被大量使用,内存直接不够了,
这个时候就需要内存淘汰策略来保护自己了。
5、聊聊Redis内存淘汰策略? redis有8种内存淘汰策略。
  • volatile-lru:当内存不足以容纳新写入数据时,从设置了过期时间的key中使用LRU(最近最少使用)算法进行淘汰;
  • allkeys-lru:当内存不足以容纳新写入数据时,从所有key中使用LRU(最近最少使用)算法进行淘汰;
  • volatile-lfu:4.0版本新增,当内存不足以容纳新写入数据时,在过期的key中,使用LFU算法进行删除key;
  • allkeys-lfu:4.0版本新增,当内存不足以容纳新写入数据时,从所有key中使用LFU算法进行淘汰;
  • volatile-random:当内存不足以容纳新写入数据时,从设置了过期时间的key中,随机淘汰数据;
  • allkeys-random:当内存不足以容纳新写入数据时,从所有key中随机淘汰数据;
  • volatile-ttl:当内存不足以容纳新写入数据时,在设置了过期时间的key中,根据过期时间进行淘汰,越早过期的优先被淘汰;
  • noeviction:默认策略,当内存不足以容纳新写入数据时,新写入操作会报错;
6、聊聊Redis事务机制? Redis通过MULTI、EXEC、WATCH等一组命令集合,来实现事务机制。事务支持一次执行多个命令,一个事务中所有命令都会被序列化。在事务执行过程,会按照顺序串行化执行队列中的命令,其他客户端提交的命令请求不会插入到事务执行命令序列中。
简言之,Redis事务就是顺序性、一次性、排他性的执行一个队列中的一系列命令。
Redis执行事务的流程如下:
  • 开始事务(MULTI)
  • 命令入队
  • 执行事务(EXEC)、撤销事务(DISCARD )
命令 描述
EXEC 执行所有事务块内的命令
DISCARD 取消事务,放弃执行事务块内的所有命令
MULTI 标记一个事务块的开始
UNWATCH 取消 WATCH 命令对所有 key 的监视。
WATCH 监视key ,如果在事务执行之前,该key 被其他命令所改动,那么事务将被打断。
有关redis事务需要注意的就是
1)与mysql中事务不同,在redis事务遇到执行错误的时候,不会进行回滚,而是简单的放过了,并保证其他的命令正常执行(所以说redis的事务并不是保证原子性)。
2)当事务的执行过程中,如果redis意外的挂了。很遗憾只有部分命令执行了,后面的也就被丢弃了。
7、说说Redis哈希槽的概念? Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念,Redis 集群有16384个哈希槽,每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽,集群的每个节点负责一部分 hash 槽。
使用哈希槽的好处就在于可以方便的添加或移除节点。这种结构无论是添加删除或者修改某一个节点,都不会造成集群不可用的状态。
当需要增加节点时,只需要把其他节点的某些哈希槽挪到新节点就可以了;
当需要移除节点时,只需要把移除节点上的哈希槽挪到其他节点就行了;
在这一点上,我们以后新增或移除节点的时候不用先停掉所有的 redis 服务。
8、为什么RedisCluster会设计成16384个槽呢? 2的14次方就是16384,这个当然不说一定要设计成16384个槽,作者对这个也做了解释。
地址如下: https://github.com/antirez/re...
1) 如果槽位为65536,发送心跳信息的消息头达8k,发送的心跳包过于庞大。
如上所述,在消息头中,当槽位为65536时,这块的大小是: 65536÷8÷1024=8kb 因为每秒钟,redis节点需要发送一定数量的ping消息作为心跳包,如果槽位为65536,这个ping消息的消息头太大了,浪费带宽。
2) redis的集群主节点数量基本不可能超过1000个。
如上所述,集群节点越多,心跳包的消息体内携带的数据越多。如果节点过1000个,也会导致网络拥堵。因此redis作者,不建议redis cluster节点数量超过1000个。 那么,对于节点数在1000以内的redis cluster集群,16384个槽位够用了。没有必要拓展到65536个。
3) 槽位越小,节点少的情况下,压缩率高
Redis主节点的配置信息中,它所负责的哈希槽是通过一张bitmap的形式来保存的,在传输过程中,会对bitmap进行压缩,但是如果bitmap的填充率slots / N很高的话(N表示节点数),bitmap的压缩率就很低。
如果节点数很少,而哈希槽数量很多的话,bitmap的压缩率就很低。
9、Redis在集群中查找key的时候,是怎么定位到具体节点的? 使用CRC16算法对key进行hash,再将hash值对16384取模,得到具体的槽位根据节点和槽位的映射信息(与集群建立连接后,客户端可以取得槽位映射信息),找到具体的节点地址 去具体的节点找key如果key不在这个节点上,则redis集群会返回moved指令,加上新的节点地址给客户端。
同时,客户端会刷新本地的节点槽位映射关系如果槽位正在迁移中,那么redis集群会返回asking指令给客户端,这是临时纠正,客户端不会刷新本地的节点槽位映射关系
10、Redis底层,使用的什么协议? RESP 英文全称是Redis Serialization Protocol,它是专门为redis设计的一套序列化协议. 这个协议其实在redis的1.2版本时就已经出现了,但是到了redis2.0才最终成为redis通讯协议的标准。
RESP主要有实现简单、解析速度快、可读性好等优点。
11、Redis的Hash冲突怎么办 Redis 中的 Hash和 Java的 HashMap 更加相似,都是数组+链表的结构,当发生 hash 发生碰撞时将会把元素追加到链表上。
在Redis中hash的内部结构也是一样的: 第一维是数组,第二维是链表.组成一个 全局哈希表
在 Java 中 HashMap 扩容是个很耗时的操作,需要去申请新的数组,扩容的成本并不低,因为需要遍历一个时间复杂度为O(n)的数组,并且为其中的每个enrty进行hash计算。加入到新数组中。
为了追求高性能,Redis 采用了渐进式 rehash 策略.这也是 hash 中最重要的部分.
redis在扩容的时候执行 rehash 策略会保留新旧两个 两个全局哈希表,查询时也会同时查询两个全局哈希表 ,Redis会将旧 全局哈希表 中的内容一点一点的迁移到新的 全局哈希表 中,当迁移完成时,就会用新的 全局哈希表 取代之前的。当 全局哈希表 移除了最后一个元素之后,这个数据结构将会被删除.
正常情况下,当 全局哈希表 中元素的个数等于数组的长度时,就会开始扩容,扩容的新数组是原数组大小的 2 倍。
如果 Redis 正在做 bgsave(持久化) 时,可能不会去扩容,因为要减少内存页的过多分离(Copy On Write).但是如果 全局哈希表 已经非常满了,元素的个数达到了数组长度的 5 倍时,Redis 会强制扩容。
12、Redis相比memcached有哪些优势
  1. Memcached 所有的值均是简单的字符串,redis 作为其替代者,支持更为丰富的数据类
  2. Redis 的速度比 Memcached 快很多
  3. Redis 可以持久化其数据
13、有哪些办法可以降低 Redis 的内存使用情况呢? 当你的业务应用在 Redis 中存储数据很少时,你可能并不太关心内存资源的使用情况。但随着业务的发展,你的业务存储在 Redis 中的数据就会越来越多。
那在使用 Redis 时,怎样做才能更节省内存呢?这里总结了4点建议:
1) 控制 key 的长度
最简单直接的内存优化,就是控制 key 的长度。
在开发业务时,你需要提前预估整个 Redis 中写入 key 的数量,如果 key 数量达到了百万级别,那么,过长的 key 名也会占用过多的内存空间。
所以,你需要保证 key 在简单、清晰的前提下,尽可能把 key 定义得短一些。
例如,原有的 key 为 user123,则可以优化为 u:bk:123。
这样一来,你的 Redis 就可以节省大量的内存,这个方案对内存的优化非常直接和高效。
2) 避免存储 bigkey
bigkey,意思就是这个key的value值很大。除了控制 key 的长度之外,你同样需要关注 value 的大小,如果大量存储 bigkey,也会导致 Redis 内存增长过快。
除此之外,客户端在读写 bigkey 时,还有产生性能问题。
所以,你要避免在 Redis 中存储 bigkey,一般建议是:
  • String:大小控制在 10KB 以下
  • List/Hash/Set/ZSet:元素数量控制在 1 万以下
3) 尽可能地都设置过期时间
Redis 数据存储在内存中,这也意味着其资源是有限的。你在使用 Redis 时,要把它当做缓存来使用,而不是数据库。
所以,你的应用写入到 Redis中的数据,尽可能地都设置 过期时间。采用这种方案,可以让 Redis 中只保留经常访问的 热数据,内存利用率也会比较高。
4) 实例设置 maxmemory + 淘汰策略
虽然你的 Redis key 都设置了过期时间,但如果你的业务应用写入量很大,并且过期时间设置得比较久,那么短期间内 Redis 的内存依旧会快速增长。
如果不控制 Redis 的内存上限,也会导致使用过多的内存资源。
对于这种场景,你需要提前预估业务数据量,然后给这个实例设置 maxmemory 控制实例的内存上限,这样可以避免 Redis 的内存持续膨胀。
配置了 maxmemory,此时你还要设置数据淘汰策略,而淘汰策略如何选择,你需要结合你的业务特点来决定。
14、Redis中获取海量数据的正确操作方式? 有时候需要从Redis实例成千上万的key中找出特定前缀的key列表来手动处理数据,可能是修改它的值,也可能是删除 key。这里就有一个问题,如何从海量的 key 中找出满足特定前缀的 key 列表来?
比如我们的用户token缓存是采用了【user_token:userid】格式的key,保存用户的token的值。这时候我们想看下有多少用户在线。
在Redis2.8版本之前,我们可以使用keys命令按照正则匹配得到我们需要的key。Redis 提供了一个简单暴力的指令 keys 用来列出所有满足特定正则字符串规则的 key。
keys user_token*

但是这个命令有一些缺点:
  • 没有 offset、limit 参数,一次性吐出所有满足条件的 key,万一实例中有几百 w 个 key 满足条件,当你看到满屏的字符串刷的没有尽头时,你就知道难受了。
  • keys 算法是遍历算法,复杂度是 O(n),如果实例中有千万级以上的 key,这个指令就会导致 Redis 服务卡顿,
  • 所有读写 Redis 的其它的指令都会被延后甚至会超时报错,因为 Redis 是单线程程序,顺序执行所有指令,其它指令必须等到当前的 keys 指令执行完了才可以继续。
  • 建议生产环境屏蔽keys命令
在满足需求和存在造成Redis卡顿之间究竟要如何选择呢?面对这个两难的抉择,Redis在2.8版本给我们提供了解决办法——scan命令
相比于keys命令,scan命令有两个比较明显的优势:
  • scan命令的时间复杂度虽然也是O(N),但它是分次进行的,不会阻塞线程。
  • scan命令提供了limit参数,可以控制每次返回结果的最大条数。
这两个优势就帮助我们解决了上面的难题,不过scan命令也并不是完美的,它返回的结果有可能重复,因此需要客户端去重这点非常重要。
15、如何使用Redis的性能更高? 1)master关闭持久化
一般我们在生产上采用的持久化策略为master关闭持久化,slave开RDB即可,必要的时候AOF和RDB都开启。
2) 不使用复杂度过高的命令
Redis 是单线程模型处理请求,在执行复杂度过高的命令时,会消耗更多的 CPU 资源,主线程中的其它请求只能等待,这时也会发生排队延迟。
所以,你需要避免执行例如 sort、sinter、sinterstore、zunionstore、zinterstore 等聚合类命令。
对于这种聚合类操作,我建议你把它放到客户端来执行,不要让 Redis 承担太多的计算工作。
3)执行 O(N) 命令时,关注 N 的大小
规避使用复杂度过高的命令,就可以高枕无忧了么?
答案是否定的。
当你在执行 O(N) 命令时,同样需要注意 N 的大小。
就好比上面说的使用keys命令,如果一次性能查询过多的数据,也会在网络传输过程中耗时过长,操作延迟变大。
所以,对于容器类型(List/Hash/Set/ZSet),在元素数量未知的情况下,一定不要无脑执行 LRANGE key 0 -1 / HGETALL / SMEMBERS / ZRANGE key 0 -1。
在查询数据时,你要遵循以下原则:
  • 先查询数据元素的数量(LLEN/HLEN/SCARD/ZCARD)
  • 元素数量较少,可一次性查询全量数据
  • 元素数量非常多,分批查询数据(LRANGE/HASCAN/SSCAN/ZSCAN)
4) 批量命令代替单个命令
当你需要一次性操作多个 key 时,你应该使用批量命令来处理。
批量操作相比于多次单个操作的优势在于,可以显著减少客户端、服务端的来回网络 IO 次数。
所以我给你的建议是:
  • String / Hash 使用 MGET/MSET 替代 GET/SET,HMGET/HMSET 替代 HGET/HSET
  • 其它数据类型使用 Pipeline,打包一次性发送多个命令到服务端执行
5) 避免集中过期 key
Redis 清理过期 key 是采用定时 + 懒惰的方式来做的,而且这个过程都是在主线程中执行。
如果你的业务存在大量 key 集中过期的情况,那么 Redis 在清理过期 key 时,也会有阻塞主线程的风险。
想要避免这种情况发生,你可以在设置过期时间时,增加一个随机时间,把这些 key 的过期时间打散,从而降低集中过期对主线程的影响。
6) 只使用 db0
尽管 Redis 提供了 16 个 db,但我只建议你使用 db0。
为什么呢?我总结了以下 3 点原因:
  • 在一个连接上操作多个 db 数据时,每次都需要先执行 SELECT,这会给 Redis 带来额外的压力
  • 使用多个 db 的目的是,按不同业务线存储数据,那为何不拆分多个实例存储呢?拆分多个实例部署,多个业务线不会互相影响,还能提高 Redis 的访问性能
  • Redis Cluster 只支持 db0,如果后期你想要迁移到 Redis Cluster,迁移成本高
16、如何解决 Redis 的并发竞争 Key 问题 这个也是线上非常常见的一个问题,就是多客户端同时并发写一个 key,可能本来应该先到的数据后到了,导致数据版本错了;或者是多客户端同时获取一个 key,修改值之后再写回去,只要顺序错了,数据就错了。
推荐一种方案:分布式锁(zookeeper和redis都可以实现分布式锁)。(如果不存在Redis的并发竞争Key问题,不要使用分布式锁,这样会影响性能)
17、使用过 Redis 做异步队列么,你是怎么用的? 一般使用list结构作为队列,rpush生产消息,lpop消费消息。当lpop没有消息的时候,要适当sleep一会再重试。
如果不想sleep呢?list还有个指令叫blpop,在没有消息的时候,它会阻塞住直到消息到来。
但如果是这样你发现redis作为消息队列是不安全的,它不能重复消费,一旦消费就会被删除。同时做消费者确认ACK也麻烦所以一般在实际开发中一般很少用redis中消息队列,因为现在已经有Kafka、RabbitMQ等成熟的消息队列了,它们的功能更加完善。
18、用Redis做延时队列,具体应该怎么实现? 延迟队列可以使用 zset(有序列表)实现,我们将消息序列化成一个字符串作为列表的value,这个消息的到期处理时间作为score,然后用定时器定时去扫描,一旦有执行时间小于或等于当前时间的任务,就立即执行。
19、使用Redis统计网站的UV,应该怎么做? UV与PV不同,UV需要去重。一般有2种方案:
1、用BitMap。存的是用户的uid,计算UV的时候,做下bitcount就行了。
2、用布隆过滤器。将每次访问的用户uid都放到布隆过滤器中。优点是省内存,缺点是无法得 到精确的UV。但是对于不需要精确知道具体UV,只需要大概的数量级的场景,是个不错的选择。
20、什么是热Key问题,如何解决热key问题 所谓热key问题就是,突然有几十万的请求去访问redis上的某个特定key。那么,这样会造成流量过于集中,达到物理网卡上限,从而导致这台redis的服务器宕机。
而热点Key是怎么产生的呢?主要原因有两个:
  • 用户消费的数据远大于生产的数据,如秒杀、热点新闻等读多写少的场景。
  • 请求分片集中,超过单Redi服务器的性能,比如固定名称key,Hash落入同一台服务器,瞬间访问量极大,超过机器瓶颈,产生热点Key问题。
那么在日常开发中,如何识别到热点key呢?
  • 凭经验判断哪些是热Key;
  • 客户端统计上报;
  • 服务代理层上报
如何解决热key问题?
  • Redis集群扩容:增加分片副本,均衡读流量;
  • 将热key分散到不同的服务器中;
  • 使用二级缓存,即JVM本地缓存,减少Redis的读请求。


参考 [1] Redis 最佳实践指南: https://mp.weixin.qq.com/s/Fz...
[2] Redis经典面试题: https://mp.weixin.qq.com/s/fB...
[3] Redis面试20题: http://www.gameboys.cn/articl...
关注公众号:后端元宇宙。持续输出优质好文

    推荐阅读