redis灵魂拷问:19图+11题带你面试通关

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
日志服务 SLS,月写入数据量 50GB 1个月
简介: redis灵魂拷问:19图+11题带你面试通关

又到了金三银四跳槽季,好多同学已经开始行动了。今天我来助力一把,送出这套redis面试题,助力大家通关。

1 redis为什么响应快

1.1数据保存在内存中

redis数据保存在内存中,读写操作只要访问内存,不需要磁盘IO

1.2.底层数据结构

  • redis的数据以key:value的格式存储在散列表中,时间复杂度o(1)
  • redisvalue定义了丰富的数据结构,包括动态字符串、双向链表、压缩列表、hash、跳表和整数数组,可以根据value的特性选择选择最高效的数据结构。

1.3.单线程模型

redis的网络IO和数据读写使用单线程模型,可以绑定CPU,这避免了线程上下文切换带来的开销。

「注意:redis6.0对网络请求引入了多线程模型,读写操作还是用单线程。」

redis多线程网络模型见下图:

微信图片_20221212181352.png

1.4.IO多路复用

redis采用epoll网络模型,如下图:

微信图片_20221212181420.png

内核会一直监听新的socket连接事件的和已建立socket连接的读写事件,把监听到的事件放到事件队列,redis使用单线程不停的处理这个事件队列。这避免了阻塞等待连接和读写事件到来。

这些事件绑定了回调函数,会调用redis的处理函数进行处理。

2 redis底层数据结构

redis有5种数据类型,包括「字符串、列表、集合、有序集合和字典」

redis底层的数据结构有6种,包括「动态字符串、双向链表、压缩列表(ziplist)、hash表、跳表(skip list)和整数数组」

redis数据类型和底层数据结构有如下对应关系:

微信图片_20221212181445.png


2.1.字符串类型

底层数据结构是动态字符串。

2.2.列表

如果同时满足下面条件,就使用压缩列表,否则使用双向链表。

  • 列表中单个元素小于64字节
  • 列表中元素个数少于 512

「压缩列表」在内存中是一块儿连续的内存空间,结构如下:

微信图片_20221212181509.png

「压缩列表查找时间复杂度是o(n)

2.3.集合

如果同时满足下面条件,就使用有序整数数组,否则使用hash表。

  • 集合中元素都是整数类型
  • 集合中元素个数不超过512

2.4.有序集合

如果同时满足下面2个条件,就使用压缩列表,否则使用跳表。

  • 集合中元素都小于64字节
  • 集合中元素个数小于128

「注意:有序集合还有一个HASH表用于保存集合中元素的分数,做ZSCORE操作时,查询的就是这个HASH表,所以效率很高。」

「跳表」的结构如下:

微信图片_20221212181535.png

如果不加索引,查找10这个数字需要查询10次,使用了二级索引,查找10这个数字需要5次,而使用一级索引,需要查询3次。

跳表的每一层都是一个有序链表,最下面一层保存了全部数据。跳表插入、删除、查询的时间复杂度是o(logN)。跳表需要存储额外的索引节点,会增加额外的空间开销。

2.5.字典

如果同时满足下面2个条件,就使用压缩列表,否则使用hash表。

  • 字典中每个entrykey/value都小于64字节
  • 字典中元素个数小于512

3 redis缓存淘汰策略

redis总共有8种淘汰策略,如下图:

微信图片_20221212181622.png

volatile-lfuallkeys-lfu策略是4.0版本新增的。

  • 「lru」是按照数据的最近最少访问原则来淘汰数据,可能存在的问题是如果大批量冷数据最近被访问了一次,就会占用大量内存空间,如果缓存满了,部分热数据就会被淘汰掉。
  • 「lfu」是按照数据的最小访问频率访问次数原则来淘汰数据,如果两个数据的访问次数相同,则把访问时间较早的数据淘汰。

4 redis数据持久化

redis持久化的方式有2种,一种是写后日志(AOF),一种是内存快照(RDB)

4.1.AOF日志

AOF日志记录了每一条收到的命令,redis故障宕机恢复时,可以加载AOF日志中的命令进行重放来进行故障恢复。AOF3种同步策略,如下图:

微信图片_20221212181648.png

如果不是对丢失数据特别敏感的业务,推荐使用everysec,对主线程的阻塞少,故障后丢失数据只有1s

4.2.RDB快照

RDB快照是一个内存快照,记录了redis某一时刻的全部数据。

4.3.混合日志

redis4.0开始,AOF文件也可以保存RDB快照,AOF重写的时候redis会把AOF文件内容清空,先记录一份RDB快照,这份数据以"REDIS"开头。记录RDB内容后,AOF文件会接着记录AOF命令。故障恢复时,先加载AOF文件中RDB快照,然后回放AOF文件中后面的命令。

4.4.主从同步

redis主从同步时,主节点会先生成一份RDB快照发送给从节点,把快照之后的命令写入主从同步缓存区(replication buffer),从节点把RDB文件加载完成后,主节点把缓存区命令发送给从节点。

4.5.AOF重写

AOF日志是用记录命令的方式追加的,这样可能存在对同一个key的多条命令,这些命令是可以合并成1条的。比如对同一个key的多个set操作日志,可以合成一条。

4.6.阻塞点

AOF重写和RDB快照执行的过程中,redis都会fork一个子进程来执行操作,子进程执行过程中是不是阻塞主线程的。

「但是要注意2点:」

  • fork子进程的过程中,redis主线程会拷贝一份内存页表(记录了虚拟内存和物理内存的映射关系)给子进程,这个过程是阻塞的,redis主线程内存越大,阻塞时间越长;
  • 子进程和redis主线程共用一块儿物理内存,如果新的请求到来,必须使用copy on write的方式,拷贝要修改的数据页到新的内存空间进行修改。如下图:

微信图片_20221212181715.png

注意:如果开启了内存大页,每次拷贝都需要分配2MB的内存。

5 redis高可用

下图是一个「一主二从三哨兵」的架构图:

微信图片_20221212181737.png

从图我们可以看到哨兵之间、哨兵和主从节点之间、哨兵和客户端之间都建立了连接。

如果主节点挂了,哨兵集群需要完成主从切换,如下图:微信图片_20221212181802.png

下面我们依次来聊一下这4个步骤「5.1~5.4」

5.1.判断主节点下线

当一个哨兵监控到主节点下线时,就会给其他哨兵发送确认命令,其他命令会根据自己的判断回复"Y""N"

如果有n/2 + 1以上数量的哨兵都认为主节点下线了,才会判定主节点下线。这里的n是哨兵集群的数量。

n/2 + 1这个参数由quorum参数配置,比如有5个哨兵,这里一般配置成3。也可以配置成其他值。

5.2.选举新主节点

主节点被判定下线后,哨兵集群会重新选择新的主节点。

5.2.1 淘汰不稳定从节点

根据配置参数down-after-milliseconds * 10来淘汰。

「down-after-milliseconds」表示主从节点断开时间,10表示次数,如果从节点跟主节点断开时间超过down-after-milliseconds的次数达到了10次以上,从节点就被淘汰了。

5.2.2 slave-priority参数

「slave-priority」参数配置了从节点的优先级,选择从节点时哨兵会优先选择优先级高的从节点。

5.2.3 复制进度

redis有一个记录主从增量复制的缓存区叫repl_backlog_buffer,这是一个环形结构的缓冲区,如下图:

微信图片_20221212181832.png


主节点有一个写偏移量master_repl_offset,从节点也有一个偏移量slave_repl_offset。优先选择slave_repl_offset最接近master_repl_offset的从节点作为新的主节点。

所以,上图中偏移量为114的从节点优先被选为新的主节点。

5.2.4 ID编号

优先级和参数都一样的情况下,ID编号小的从节点优先被选为新主节点。

5.3.选举哨兵leader

第一个判断主节点下线的哨兵节点收到其他节点的回复并确定主节点下线后,就会给其他哨兵发送命令申请成为哨兵leader

「成为leader的条件如下:」

  • 收到赞成票必须大于等quorum
  • 必须拿到半数以上的赞成票

如果集群配置了5个哨兵,quorum的值设置为3,其中一个哨兵节点挂了,很有可能会判断到主节点下线,但是因为选举不出哨兵leader而不能切换。如果集群有2个哨兵,其中一个挂了,那必定选不出哨兵leader

下面的图展示了哨兵一成功当选leader的过程:

微信图片_20221212181856.png


5.4.主节点切换

选出新主节点和哨兵leader后,哨兵leader会执行主从切换的操作。完成后会做一些「事件通知」

  • 通知其他哨兵新主节点地址
  • 通知所有从节点新的主节点地址,从节点收到后向新主节点请求主从同步
  • 通知客户端连接新主节点

5.5.主从切换过程中请求处理

如果客户端的读请求会发送到从节点,可以正常处理。

在客户端收到新主节点地址通知前写请求会失败。

客户端可以采取一些应急措施应对主节点下线,比如缓存写请求。

为了能够及时获取到新主节点信息,客户端可以订阅哨兵的主节点下线事件和新主节点变更事件。

6 redis为什么变慢了

redis变慢了的原因有很多,总结一下有11个,见下图:

微信图片_20221212181919.png

从图中看出,redis变慢原因主要有两类:「阻塞主线程和操作系统限制」

6.1主线程阻塞

6.1.1.AOF重写和RDB快照

前面已经讲过了,redisAOF重写时,主线程会fork出一个bgrewriteaof子进程。

redis进行RDB快照时主线程会fork出一个bgsave子进程。

这两个操作表面上看不阻塞主线程,但fork子进程的这个过程是在主线程完成的。fork子进程时redis需要拷贝内存页表,如果redis实例很大,这个拷贝会耗费大量的CPU资源,阻塞主线程的时间也会变长。

6.1.2.内存大页

redis默认支持内存大页是2MB,使用内存大页,一定程度上可以减少redis的内存分配次数,但是对数据持久化会有一定影响。

redisAOF重写和RDB快照过程中,如果主线程收到新的写请求,就需要CopyOnWrite。使用了内存大页,即使redis只修改其中一个大小是1kbkey,也需要拷贝一整页的数据,即2MB。在写入量较多时,大量拷贝就会导致redis性能下降。

6.1.3.命令复杂度高

执行复杂度高的命令是造成redis阻塞的常见原因。比如对一个set或者list数据类型执行SORT操作,复杂度是O(N+M*log(M))

6.1.4.bigkey操作

如果一个keyvalue非常大,创建的时候分配内存会很耗时,删除的时候释放内存也很耗时。

redis4.0以后引入了layfree机制,可以使用子进程异步删除,从而不影响主线程执行。用UNLINK命令替代DEL命令,就可以使用子进程异步删除。

redis6.0增加了配置项lazyfree-lazy-user-del,配置成yes后,del命令也可以用子进程异步删除。

如果lazyfree-lazy-user-del不设置为yes,那redis是否采用异步删除,是要看删除的时机的。对于String类型和底层采用整数数组和压缩列表的数据类型,redis是不会采用异步删除的。

6.1.5.从节点全量同步

从节点全量同步过程中,需要先清除内存中的数据,然后再加载RDB文件,这个过程中是阻塞的,如果有读请求到来,只能等到加载RDB文件完成后才能处理请求,所以响应会很慢。

另外,如果redis实例很大,也会造成RDB文件太大,从库加载时间长。所以尽量保持redis实例不要太大,比如单个实例限制4G,如果超出就采用切片集群。

6.1.6.AOF同步写盘

appendfsync策略有3种:always、everysec、no,如果采用always,每个命令都会同步写盘,这个过程是阻塞的,等写盘成功后才能处理下一条命令。

除非是严格不能丢数据的场景,否则尽量不要选择always策略,推荐尽量选择everysec策略,如果对丢失数据不敏感,可以采用no

6.1.7.内存达到maxmemory

内存达到maxmemory,需要使用淘汰策略来淘汰部分key。即使采用lazyfree异步删除,选择key的过程也是阻塞的。

可以选择较快的淘汰策略,比如用随机淘汰来替换LRULFU算法淘汰。也可以扩大切片数量来减轻淘汰key的时间消耗。

6.2操作系统限制

6.2.1.使用了swap

使用swap的原因是操作系统不能给redis分配足够大的内存,如果操作其他开启了swap,内存数据就需要不停地跟swap换入和换出,对性能影响非常大。

操作系统没有能力分配内存的原因也可能是其他进程使用了大量的内存。

6.2.2.网络问题

如果网卡负载很大,对redis性能影响会很大。这一方面有可能redis的访问量确实很高,另一方面也可能是有其他流量大的程序占用了带宽。

这个最好从运维层面进行监控。

6.2.3.线程上下文切换

redis虽然是单线程的,但是在多核cpu的情况下,也可能会发生上下文切换。如果主线程从一个物理核切换到了另一个物理核,那就不能使用CPU高效的一级缓存和二级缓存了。如下图所示:

微信图片_20221212181948.png

为防止这种情况,可以把redis绑定到一个CPU物理核。

6.2.4.磁盘性能低

对于AOF同步写盘的使用场景,如果磁盘性能低,也会影响redis的响应。可以优先采用性能更好的SSD硬盘。

7 设计排行榜功能

rediszset类型保存了分数值,可以方便的实现排行榜的功能。

比如要统计10篇文章的排行榜,可以先建立一个存放10篇文章的zset,每当有读者阅读一篇文章时,就用ZINCRBY命令给这篇文章的分数加1,最后可以用range命令统计排行榜前几位的文章。

8 redis实现分布式锁

8.1.redis单节点的分布式锁

如下图,一个服务部署了2个客户端,获取分布式锁时一个成功,另一个就失败了。

微信图片_20221212182019.png

redis一般使用setnx实现分布式锁,命令如下:

SETNX KEY_NAME VALUE

设置成功返回 1,设置失败返回 0

使用单节点分布式锁存在一些问题。

8.1.1.客户端1获取锁后发生了故障

结果锁就不能释放了,其他客户端永远获取不到锁。解决方法是用下面命令对key设置过期时间:

SET key value [EX seconds] [PX milliseconds] NX

8.1.2 客户端2误删除了锁

解决方法是对key设置value时加入一个客户端表示,比如在客户端1设置key时在value前拼接一个字符串application1,删除的时候做一下判断。

8.2.redis红锁

redis单节点会有可靠性问题,节点故障后锁操作就会失败。redis为了应对单点故障的问题,设计了多节点的分布式锁,也叫红锁。主要思想是客户端跟多个redis实例请求加锁,只有超过半数的实例加锁成功,才认为成功获取了分布式锁。

如下图,客户端分别跟3个实例请求加锁,有2个实例加锁成功,所以获取分布式锁成功:

微信图片_20221212182046.png


9 缓存雪崩、击穿、穿透

9.1.缓存雪崩

redis做缓存时,如果同一时间大量缓存数据失效,客户端请求会大量发送到数据库,导致数据库压力激增。如下图:

微信图片_20221212182110.png

「应对方法主要有3个:」

  • 给key设置过期时间时加一个小的随机数
  • 限流
  • 服务降级

9.2.缓存击穿

某个热点key,突然过期了,大量请求发送到了数据库。解决方案是给热点key不设置过期时间。

9.3.缓存穿透

某个热点key,查询缓存和查询数据库都没有,就发生了缓存穿透。如下图:

微信图片_20221212182131.png

「应对方法主要有2个:」

  • 缓存热点的空值和缺省值
  • 查询数据库之前先查询布隆过滤器

10 数据倾斜

什么是数据倾斜?看下面这个面试题:

如果redis有一个热点keyqps能达到100w,该如何存储?

如果这个热点key被放到一个redis实例上,这个实例面临的访问压力会非常大。如下图,redis3这个实例保存了foo这个热点key,访问压力会很大:

微信图片_20221212182218.png

「解决方法主要有两个:」

1.使用客户端本地缓存来缓存key,这样改造会有两个问题:

  • 客户端缓存的热点key可能消耗大量内存
  • 客户端需要保证本地缓存和redis缓存的一致性

2.给热点key加一个随机前缀,让它保存到不同的redis实例上,这样也会存在两个问题:

  • 客户端在访问的时候需要给这个key加前缀
  • 客户端在删除的时候需要根据所有前缀来删除不同实例上保存的这个key

11 bitmap使用

有一道经典的面试题,10亿整数怎么在内存中去重排序?

我们先算一下10亿整数占的内存,java一个整数类型占四字节,占用内存大小约

10亿 * 4 / 1024 / 1024 = 3.7G

占得内存太大了,如果内存不够,怎么办呢?

11.1.bitmap介绍

bitmap类型使用的数据结构是String,底层存储格式是二进制的bit数组。假如我们有1、4、6、9四个数,保存在bit数组中如下图:

微信图片_20221212182255.png

在这个bit数组中用10bit的空间保存了四个整数,占用空间非常小。

再回到面试题,我们使用bit数组长度是10亿整数中 「(最大值 - 最小值 + 1)」

如果有负数,需要进行一个转化,所有数字加最小负数的绝对值。比如{-2, 0, 1, 3},我们转换成{0, 2, 3, 5},因为数组下标必须从0开始

11.2.使用场景

11.2.1.员工打卡记录

在一个有100个员工的公司,要统计一个月内员工全勤的人数,可以每天创建一个bitmap,签到的员工bit位置为1

要统计当天签到的员工只要用BITCOUNT命令就可以。

要统计当月全勤的员工,只要对当月每天的bitmap做交集运算就可以,命令如下:

BITOP AND srckey1 srckey2 srckey3 ... srckey30

srckeyN表示第N天的打卡记录bitmap

11.2.2.统计网站日活跃用户

比如网站有10万个用户,这样我们创建一个长度为10万的bitmap,每个用户id占一个位,如果用户登录,就把bit位置为1,日终的时候用BITCOUNT命令统计出当天登录过的用户总数。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
24天前
|
存储 NoSQL Java
可能是最漂亮的Redis面试基础详解
我是南哥,相信对你通关面试、拿下Offer有所帮助。敲黑板:本文总结了Redis基础最常见的面试题!包含了Redis五大基本数据类型、Redis内存回收策略、Redis持久化等。相信大部分Redis初学者都会忽略掉一个重要的知识点,Redis其实是单线程模型。我们按直觉来看应该是多线程比单线程更快、处理能力更强才对,比如单线程一次只可以做一件事情,而多线程却可以同时做十件事情。但Redis却可以做到每秒万级别的处理能力,主要是基于以下原因:(1)Redis是基于内存操作的,Redis所有的数据库状态都保存在
可能是最漂亮的Redis面试基础详解
|
11天前
|
NoSQL Java API
美团面试:Redis锁如何续期?Redis锁超时,任务没完怎么办?
在40岁老架构师尼恩的读者交流群中,近期有小伙伴在面试一线互联网企业时遇到了关于Redis分布式锁过期及自动续期的问题。尼恩对此进行了系统化的梳理,介绍了两种核心解决方案:一是通过增加版本号实现乐观锁,二是利用watch dog自动续期机制。后者通过后台线程定期检查锁的状态并在必要时延长锁的过期时间,确保锁不会因超时而意外释放。尼恩还分享了详细的代码实现和原理分析,帮助读者深入理解并掌握这些技术点,以便在面试中自信应对相关问题。更多技术细节和面试准备资料可在尼恩的技术文章和《尼恩Java面试宝典》中获取。
美团面试:Redis锁如何续期?Redis锁超时,任务没完怎么办?
|
18天前
|
NoSQL 算法 Redis
Redis面试篇
Redis面试篇
31 5
|
19天前
|
缓存 NoSQL Java
Java中redis面试题
Java中redis面试题
28 1
|
24天前
|
NoSQL Redis
redis 的 key 过期策略是怎么实现的(经典面试题)超级通俗易懂的解释!
本文解释了Redis实现key过期策略的方式,包括定期删除和惰性删除两种机制,并提到了Redis的内存淘汰策略作为补充,以确保过期的key能够被及时删除。
44 1
|
2月前
|
缓存 监控 NoSQL
阿里面试让聊一聊Redis 的内存淘汰(驱逐)策略
大家好,我是 V 哥。粉丝小 A 面试阿里时被问到 Redis 的内存淘汰策略问题,特此整理了一份详细笔记供参考。Redis 的内存淘汰策略决定了在内存达到上限时如何移除数据。希望这份笔记对你有所帮助!欢迎关注“威哥爱编程”,一起学习与成长。
|
17天前
|
缓存 NoSQL 算法
面试题:Redis如何实现分布式锁!
面试题:Redis如何实现分布式锁!
|
3月前
|
存储 Java
【IO面试题 四】、介绍一下Java的序列化与反序列化
Java的序列化与反序列化允许对象通过实现Serializable接口转换成字节序列并存储或传输,之后可以通过ObjectInputStream和ObjectOutputStream的方法将这些字节序列恢复成对象。
|
20天前
|
算法 Java 数据中心
探讨面试常见问题雪花算法、时钟回拨问题,java中优雅的实现方式
【10月更文挑战第2天】在大数据量系统中,分布式ID生成是一个关键问题。为了保证在分布式环境下生成的ID唯一、有序且高效,业界提出了多种解决方案,其中雪花算法(Snowflake Algorithm)是一种广泛应用的分布式ID生成算法。本文将详细介绍雪花算法的原理、实现及其处理时钟回拨问题的方法,并提供Java代码示例。
47 2
|
24天前
|
JSON 安全 前端开发
第二次面试总结 - 宏汉科技 - Java后端开发
本文是作者对宏汉科技Java后端开发岗位的第二次面试总结,面试结果不理想,主要原因是Java基础知识掌握不牢固,文章详细列出了面试中被问到的技术问题及答案,包括字符串相关函数、抽象类与接口的区别、Java创建线程池的方式、回调函数、函数式接口、反射以及Java中的集合等。
23 0