本系列会系统的整理 MySQL,Redis,SSM 框架,算法,计网等面试常问技术栈的面试题,本文主要是整理分.享了 Redis 相关的面试题,MySQL、Spring、JVM 之前已经更新了,需要的同学也可以去看一下,希望对正在准备秋招的你们有所帮助!
1. 什么是 Redis?它主要用来什么的?
Redis,英文全称是 Remote Dictionary Server(远程字典服务),是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库,并提供多种语言的 API。
与 MySQL 数据库不同的是,Redis 的数据是存在内存中的。它的读写速度非常快,每秒可以处理超过 10 万次读写操作。因此 redis 被广泛应用于缓存,另外,Redis 也经常用来做分布式锁。除此之外,Redis 支持事务、持久化、LUA 脚本、LRU 驱动事件、多种集群方案。
2.说说 Redis 的基本数据结构类型
大多数小伙伴都知道,Redis 有以下这五种基本类型:
它还有三种特殊的数据结构类型
2.1 Redis 的五种基本数据类型
编辑
String(字符串)
C 语言的字符串是 char[]实现的,而 Redis 使用 SDS(simple dynamic string)封装,sds 源码如下:
structsdshdr{unsignedintlen; // 标记buf的长度unsignedintfree; //标记buf中未使用的元素个数charbuf[]; // 存放元素的坑}
复制代码
SDS 结构图如下:
编辑
Redis 为什么选择 SDS 结构,而 C 语言原生的 char[]不香吗?
举例其中一点,SDS 中,O(1)时间复杂度,就可以获取字符串长度;而 C 字符串,需要遍历整个字符串,时间复杂度为 O(n)
Hash(哈希)
字符串和哈希类型对比如下图:
编辑
List(列表)
一图看懂 list 类型的插入与弹出:
编辑
list 应用场景参考以下:
lpush+lpop=Stack(栈)
lpush+rpop=Queue(队列)
lpsh+ltrim=Capped Collection(有限集合)
lpush+brpop=Message Queue(消息队列)
Set(集合)
编辑
有序集合(zset)
2.2 Redis 的三种特殊数据类型
3. Redis 为什么这么快?
编辑
3.1 基于内存存储实现
我们都知道内存读写是比在磁盘快很多的,Redis 基于内存存储实现的数据库,相对于数据存在磁盘的 MySQL 数据库,省去磁盘 I/O 的消耗。
3.2 高效的数据结构
我们知道,Mysql 索引为了提高效率,选择了 B+树的数据结构。其实合理的数据结构,就是可以让你的应用/程序更快。先看下 Redis 的数据结构 &内部编码图:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(
img-bQuqNANR-1657354189274)(
https://upload-images.jianshu.io/upload_images/27937678-e4efc48d74dd5939.png?
imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
SDS 简单动态字符串
编辑
字符串长度处理:Redis 获取字符串长度,时间复杂度为 O(1),而 C 语言中,需要从头开始遍历,复杂度为 O(n);
空间预分配:字符串修改越频繁的话,内存分配越频繁,就会消耗性能,而 SDS 修改和空间扩充,会额外分配未使用的空间,减少性能损耗。
惰性空间释放:SDS 缩短时,不是回收多余的内存空间,而是 free 记录下多余的空间,后续有变更,直接使用 free 中记录的空间,减少分配。
二进制安全:Redis 可以存储一些二进制数据,在 C 语言中字符串遇到'\0'会结束,而 SDS 中标志字符串结束的是 len 属性。
字典
Redis 作为 K-V 型内存数据库,所有的键值就是用字典来存储。字典就是哈希表,比如 HashMap,通过 key 就可以直接获取到对应的 value。而哈希表的特性,在 O(1)时间复杂度就可以获得对应的值。
跳跃表
编辑
跳跃表是 Redis 特有的数据结构,就是在链表的基础上,增加多级索引提升查找效率。
跳跃表支持平均 O(logN),最坏 O(N)复杂度的节点查找,还可以通过顺序性操作批量处理节点。
3.3 合理的数据编码
Redis 支持多种数据数据类型,每种基本类型,可能对多种数据结构。什么时候,使用什么样数据结构,使用什么样编码,是 redis 设计者总结优化的结果。
String:如果存储数字的话,是用 int 类型的编码;如果存储非数字,小于等于 39 字节的字符串,是 embstr;大于 39 个字节,则是 raw 编码。
List:如果列表的元素个数小于 512 个,列表每个元素的值都小于 64 字节(默认),使用 ziplist 编码,否则使用 linkedlist 编码
Hash:哈希类型元素个数小于 512 个,所有值小于 64 字节的话,使用 ziplist 编码,否则使用 hashtable 编码。
Set:如果集合中的元素都是整数且元素个数小于 512 个,使用 intset 编码,否则使用 hashtable 编码。
Zset:当有序集合的元素个数小于 128 个,每个元素的值小于 64 字节时,使用 ziplist 编码,否则使用 skiplist(跳跃表)编码
3.4 合理的线程模型
I/O 多路复用
编辑
I/O 多路复用
多路 I/O 复用技术可以让单个线程高效的处理多个连接请求,而 Redis 使用用 epoll 作为 I/O 多路复用技术的实现。并且,Redis 自身的事件处理模型将 epoll 中的连接、读写、关闭都转换为事件,不在网络 I/O 上浪费过多的时间。
什么是 I/O 多路复用?
I/O :网络 I/O
多路 :多个网络连接
复用:复用同一个线程。
IO 多路复用其实就是一种同步 IO 模型,它实现了一个线程可以监视多个文件句柄;一旦某个文件句柄就绪,就能够通知应用程序进行相应的读写操作;而没有文件句柄就绪时,就会阻塞应用程序,交出 cpu。
单线程模型
3.5 虚拟内存机制
Redis 直接自己构建了 VM 机制 ,不会像一般的系统会调用系统函数处理,会浪费一定的时间去移动和请求。
Redis 的虚拟内存机制是啥呢?
虚拟内存机制就是暂时把不经常访问的数据(冷数据)从内存交换到磁盘中,从而腾出宝贵的内存空间用于其它需要访问的数据(热数据)。通过 VM 功能可以实现冷热数据分离,使热数据仍在内存中、冷数据保存到磁盘。这样就可以避免因为内存不足而造成访问速度下降的问题。
4. 什么是缓存击穿、缓存穿透、缓存雪崩?
4.1 缓存穿透问题
先来看一个常见的缓存使用方式:读请求来了,先查下缓存,缓存有值命中,就直接返回;缓存没命中,就去查数据库,然后把数据库的值更新到缓存,再返回。
编辑
缓存穿透:指查询一个一定不存在的数据,由于缓存是不命中时需要从数据库查询,查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到数据库去查询,进而给数据库带来压力。
通俗点说,读请求访问时,缓存和数据库都没有某个值,这样就会导致每次对这个值的查询请求都会穿透到数据库,这就是缓存穿透。
缓存穿透一般都是这几种情况产生的:
如何避免缓存穿透呢?一般有三种方法。
布隆过滤器原理:它由初始值为 0 的位图数组和 N 个哈希函数组成。一个对一个 key 进行 N 个 hash 算法获取 N 个值,在比特数组中将这 N 个值散列后设定为 1,然后查的时候如果特定的这几个位置都为 1,那么布隆过滤器判断该 key 存在。
4.2 缓存雪奔问题
缓存雪奔:指缓存中数据大批量到过期时间,而查询数据量巨大,请求都直接访问数据库,引起数据库压力过大甚至 down 机。
4.3 缓存击穿问题
缓存击穿:指热点 key 在某个时间点过期的时候,而恰好在这个时间点对这个 Key 有大量的并发请求过来,从而大量的请求打到 db。
缓存击穿看着有点像,其实它两区别是,缓存雪奔是指数据库压力过大甚至 down 机,缓存击穿只是大量并发请求到了 DB 数据库层面。可以认为击穿是缓存雪奔的一个子集吧。有些文章认为它俩区别,是区别在于击穿针对某一热点 key 缓存,雪奔则是很多 key。
解决方案就有两种:
5. 什么是热 Key 问题,如何解决热 key 问题
什么是热 Key 呢?在 Redis 中,我们把访问频率高的 key,称为热点 key。
如果某一热点 key 的请求到服务器主机时,由于请求量特别大,可能会导致主机资源不足,甚至宕机,从而影响正常的服务。
编辑
而热点 Key 是怎么产生的呢?主要原因有两个:
用户消费的数据远大于生产的数据,如秒杀、热点新闻等读多写少的场景。
请求分片集中,超过单 Redi 服务器的性能,比如固定名称 key,Hash 落入同一台服务器,瞬间访问量极大,超过机器瓶颈,产生热点 Key 问题。
那么在日常开发中,如何识别到热点 key 呢?
凭经验判断哪些是热 Key;
客户端统计上报;
服务代理层上报
如何解决热 key 问题?
Redis 集群扩容:增加分片副本,均衡读流量;
将热 key 分散到不同的服务器中;
使用二级缓存,即 JVM 本地缓存,减少 Redis 的读请求。
6. Redis 过期策略和内存淘汰策略
编辑
6.1 Redis 的过期策略
我们在 set key 的时候,可以给它设置一个过期时间,比如 expire key 60。指定这 key60s 后过期,60s 后,redis 是如何处理的嘛?我们先来介绍几种过期策略:
定时过期
每个设置过期时间的 key 都需要创建一个定时器,到过期时间就会立即对 key 进行清除。该策略可以立即清除过期的数据,对内存很友好;但是会占用大量的 CPU 资源去处理过期的数据,从而影响缓存的响应时间和吞吐量。
惰性过期
只有当访问一个 key 时,才会判断该 key 是否已过期,过期则清除。该策略可以最大化地节省 CPU 资源,却对内存非常不友好。极端情况可能出现大量的过期 key 没有再次被访问,从而不会被清除,占用大量内存。
定期过期
每隔一定的时间,会扫描一定数量的数据库的 expires 字典中一定数量的 key,并清除其中已过期的 key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得 CPU 和内存资源达到最优的平衡效果。
expires 字典会保存所有设置了过期时间的 key 的过期时间数据,其中,key 是指向键空间中的某个键的指针,value 是该键的毫秒精度的 UNIX 时间戳表示的过期时间。键空间是指该 Redis 集群中保存的所有键。
Redis 中同时使用了惰性过期和定期过期两种过期策略。
但是呀,如果定期删除漏掉了很多过期的 key,然后也没走惰性删除。就会有很多过期 key 积在内存内存,直接会导致内存爆的。或者有些时候,业务量大起来了,redis 的 key 被大量使用,内存直接不够了,运维小哥哥也忘记加大内存了。难道 redis 直接这样挂掉?不会的!Redis 用 8 种内存淘汰策略保护自己~
6.2 Redis 内存淘汰策略
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:默认策略,当内存不足以容纳新写入数据时,新写入操作会报错。
7.说说 Redis 的常用应用场景
7.1 缓存
我们一提到 redis,自然而然就想到缓存,国内外中大型的网站都离不开缓存。合理的利用缓存,比如缓存热点数据,不仅可以提升网站的访问速度,还可以降低数据库 DB 的压力。并且,Redis 相比于 memcached,还提供了丰富的数据结构,并且提供 RDB 和 AOF 等持久化机制,强的一批。
7.2 排行榜
当今互联网应用,有各种各样的排行榜,如电商网站的月度销量排行榜、社交 APP 的礼物排行榜、小程序的投票排行榜等等。Redis 提供的 zset 数据类型能够实现这些复杂的排行榜。
比如,用户每天上传视频,获得点赞的排行榜可以这样设计:
zadduser:ranking:2021-03-03Jay3
复制代码
zincrbyuser:ranking:2021-03-03Jay1
复制代码
zremuser:ranking:2021-03-03John
复制代码
zrevrangebyrankuser:ranking:2021-03-030 2
复制代码
7.3 计数器应用
各大网站、APP 应用经常需要计数器的功能,如短视频的播放数、电商网站的浏览数。这些播放数、浏览数一般要求实时的,每一次播放和浏览都要做加 1 的操作,如果并发量很大对于传统关系型数据的性能是一种挑战。Redis 天然支持计数功能而且计数的性能也非常好,可以说是计数器系统的重要选择。
7.4 共享 Session
如果一个分布式 Web 服务将用户的 Session 信息保存在各自服务器,用户刷新一次可能就需要重新登录了,这样显然有问题。实际上,可以使用 Redis 将用户的 Session 进行集中管理,每次用户更新或者查询登录信息都直接从 Redis 中集中获取。
7.5 分布式锁
几乎每个互联网公.司中都使用了分布式部署,分布式服务下,就会遇到对同一个资源的并发访问的技术难题,如秒杀、下单减库存等场景。
7.6 社交网络
赞/踩、粉丝、共同好友/喜好、推送、下拉刷新等是社交网站的必备功能,由于社交网站访问量通常比较大,而且传统的关系型数据不太适保存 这种类型的数据,Redis 提供的数据结构可以相对比较容易地实现这些功能。
7.7 消息队列
消息队列是大型网站必用中间件,如 ActiveMQ、RabbitMQ、Kafka 等流行的消息队列中间件,主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis 提供了发布/订阅及阻塞队列功能,能实现一个简单的消息队列系统。另外,这个不能和专业的消息中间件相比。
7.8 位操作
用于数据量上亿的场景下,例如几亿用户系统的签到,去重登录次数统计,某用户是否在.线状态等等。腾讯 10 亿用户,要几个毫秒内查询到某个用户是否在.线,能怎么做?千万别说给每个用户建立一个 key,然后挨个记(你可以算一下需要的内存会很恐怖,而且这种类似的需求很多。这里要用到位操作——使用 setbit、getbit、bitcount 命令。原理是:redis 内构建一个足够长的数组,每个数组元素只能是 0 和 1 两个值,然后这个数组的下标 index 用来表示用户 id(必须是数字哈),那么很显然,这个几亿长的大数组就能通过下标和元素值(0 和 1)来构建一个记忆系统。
8. Redis 的持久化机制有哪些?优缺点说说
Redis 是基于内存的非关系型 K-V 数据库,既然它是基于内存的,如果 Redis 服务器挂了,数据就会丢失。为了避免数据丢失了,Redis 提供了持久化,即把数据保存到磁盘。
Redis 提供了 RDB 和 AOF 两种持久化机制,它持久化文件加载流程如下:
编辑
8.1 RDB
RDB,就是把内存数据以快照的形式保存到磁盘上。
什么是快照?可以这样理解,给当前时刻的数据,拍一张照片,然后保存下来。
RDB 持久化,是指在指定的时间间隔内,执行指定次数的写操作,将内存中的数据集快照写入磁盘中,它是 Redis 默认的持久化方式。执行完操作后,在指定目录下会生成一个 dump.rdb 文件,Redis 重启的时候,通过加载 dump.rdb 文件来恢复数据。RDB 触发机制主要有以下几种:
编辑
RDB 的优点
RDB 缺点
AOF
AOF(append only file)持久化,采用日志的形式来记录每个写操作,追加到文件中,重启时再重新执行 AOF 文件中的命令来恢复数据。它主要解决数据持久化的实时性问题。默认是不开启的。
AOF 的工作流程如下:
编辑
AOF 的优点
AOF 的缺点
9.怎么实现 Redis 的高可用?
我们在项目中使用 Redis,肯定不会是单点部署 Redis 服务的。因为,单点部署一旦宕机,就不可用了。为了实现高可用,通常的做法是,将数据库复制多个副本以部署在不同的服务器上,其中一台挂了也可以继续提供服务。Redis 实现高可用有三种部署模式:主从模式,哨兵模式,集群模式。
9.1 主从模式
主从模式中,Redis 部署了多台机器,有主节点,负责读写操作,有从节点,只负责读操作。从节点的数据来自主节点,实现原理就是主从复制机制
主从复制包括全量复制,增量复制两种。一般当 slave 第一次启动连接 master,或者认为是第一次连接,就采用全量复制,全量复制流程如下:
编辑
redis2.8 版本之后,已经使用 psync 来替代 sync,因为 sync 命令非常消耗系统资源,psync 的效率更高。
slave 与 master 全量同步之后,master 上的数据,如果再次发生更新,就会触发增量复制。
当 master 节点发生数据增减时,就会触发 replicationFeedSalves()函数,接下来在 Master 节点上调用的每一个命令会使用 replicationFeedSlaves()来同步到 Slave 节点。执行此函数之前呢,master 节点会判断用户执行的命令是否有数据更新,如果有数据更新的话,并且 slave 节点不为空,就会执行此函数。这个函数作用就是:把用户执行的命令发送到所有的 slave 节点,让 slave 节点执行。流程如下: