可能是最漂亮的Redis面试基础详解

2024-10-09 18:25:58 浏览数 (1)

先赞后看,Java进阶一大半

我是南哥,相信对你通关面试、拿下Offer有所帮助。

敲黑板:本文总结了Redis基础最常见的面试题!

包含了Redis五大基本数据类型、Redis内存回收策略、Redis持久化等。

1. Redis快的秘密

面试官:Redis什么这么快?

相信大部分Redis初学者都会忽略掉一个重要的知识点,Redis其实是单线程模型。我们按直觉来看应该是多线程比单线程更快、处理能力更强才对,比如单线程一次只可以做一件事情,而多线程却可以同时做十件事情。

但Redis却可以做到每秒万级别的处理能力,主要是基于以下原因:

(1)Redis是基于内存操作的,Redis所有的数据库状态都保存在内存中。而内存的响应时长是非常快速的,大约在100纳秒。大家可以对比下其他服务器磁盘,固态硬盘(SSD)、机械硬盘(HDD)响应时长大约几十微秒,很明显远远没有基于内存的响应时长快速。

(2)Redis采用I/O多路复用技术,这种I/O模型是非阻塞I/O,应用程序在等待I/O操作完成的过程中不需要阻塞。

(3)最后一点也是我开头提到的,Redis采用了单线程模型。单线程模型避免了多线程产生的线程切换和锁竞争带来的资源消耗,这两种消耗对性能影响是很大的。另外一点是单线程相比多线程来说实现更简单高效,如果引入多线程设计相信Redis实现起来会更加复杂不易优化。

2. Redis数据类型

2.1 Redis五大基本数据类型

面试官:你说说Redis五大基本数据类型?

Redis基本数据类型一共有五种,这也是面试官重点考查的基础,大家要重点关注下。

(1)字符串。

字符串是Redis最基础,也是业务开发中最常见的一种数据类型。在业务上一般使用MySQL作为实际存储层,而Redis字符串作为缓冲层对象。

代码语言:sh复制
127.0.0.1:6379> set name JavaGetOffer
OK
127.0.0.1:6379> get name
"JavaGetOffer"

(2)哈希。

哈希的键值本身是一个键值对结构,类似于key = {{field, value}, {field, value}}

我们可以使用hset命令设置哈希键值,而hget命令可以获取哈希对象中某个field的值。

代码语言:sh复制
127.0.0.1:6379> hset msg name JavaGetOffer
(integer) 1
127.0.0.1:6379> hset msg avator 思考的陈
(integer) 1
127.0.0.1:6379> hget msg name
"JavaGetOffer"
127.0.0.1:6379> hget msg avator
"思考的陈"

(3)列表。

Redis的列表是一个有序列表,但大家注意一点,此处所说的有序不是按数据大小排序的有序,而是按插入顺序的有序。另外一点特殊之处是我们可以往列表的左右两边添加元素。

代码语言:sh复制
# 从右边添加
127.0.0.1:6379> rpush number 1 2 3
(integer) 3
# 从左边添加
127.0.0.1:6379> lpush number 4 5 6
(integer) 6
127.0.0.1:6379> lrange number 0 5
1) "6"
2) "5"
3) "4"
4) "1"
5) "2"
6) "3"

(4)集合。

集合类型和列表不同之处在于它是无序的,同时也不支持保存重复的元素

另外两个集合之间可以获得交集、并集、差集。利用这一点,如果在业务上要求得两个用户相同的兴趣标签,可以使用Redis集合存储用户兴趣标签,再使用交集命令来查询。

代码语言:sh复制
127.0.0.1:6379> sadd user:1:like game bask run
(integer) 3
127.0.0.1:6379> sadd user:2:like game basketball fitness
(integer) 3
# 求交集
127.0.0.1:6379> sinter user:1:like user:2:like
1) "game"

(5)有序集合。

有序集合算是Redis中比较特殊的一种数据类型,有序集合里的每个元素都带有一个score属性,通过该score属性进行排序。如果我们往有序集合插入元素,此时它就不像列表对象一样是插入有序,而是根据score进行排序的。

代码语言:sh复制
127.0.0.1:6379> zadd 100run:ranking 13 mike
(integer) 1
127.0.0.1:6379> zadd 100run:ranking 12 jake
(integer) 1
127.0.0.1:6379> zadd 100run:ranking 16 tom
(integer) 1
127.0.0.1:6379> zrange 100run:ranking 0 2
1) "jake"
2) "mike"
3) "tom"

2.2 有序集合业务场景

面试官:有利用过有序集合开发过什么功能吗?

有序集合典型的业务开发场景是实现一个排行榜,我们可以通过有序集合的score元素来作为排行榜排序的标准。

而排行榜的获取一般是分页获取,我们可以使用jedis客户端提供的zrevrangeWithScores方法来获得,返回的类型是一个Set<Tuple>,从Tuple对象中可以获得元素和score值,如代码所示。

代码语言:java复制
        try (Jedis jedis = jedisPool.getResource()) {
            String rankKey = "rankKey";
            Set<Tuple> rankTuple = jedis.zrevrangeWithScores(rankKey, index, index   pageSize - 1);

            List<UserRankBO> = rankTuple.stream().map(r -> UserRankBO.builder()
                    .uid(Integer.parseInt(r.getElement()))
                    .score(r.getScore())
                    .build()).collect(Collectors.toList());
        }
代码语言:java复制
    public Set<Tuple> zrevrangeWithScores(String key, long start, long stop) {
        this.checkIsInMultiOrPipeline();
        this.client.zrevrangeWithScores(key, start, stop);
        return this.getTupledSet();
    }

2.3 有序集合数据结构

面试官:有序集合用什么数据结构来实现?

有序集合有两种内部编码:ziplist和skiplist。ziplist编码是以压缩列表来实现,而在skiplist编码中是同时使用字典和跳跃表两种数据结构来实现,原因下个面试官问题有提及。

(1)字典。

字典里保存的是键值对结构,和上文提交的哈希对象不是同一个级别的产物,字典是Redis内部的数据结构,而哈希对象是提供给外部使用的。例如存储键的键空间、存储建过期时间的过期字典都是由字典来实现的。

字典的组成结构如下所示。可以看到ht数组有两个dictht哈希表,Redis的平常使用时只使用其中一个哈希表,而另一个是在迁移扩展哈希表rehash时使用。当迁移完成后,原先日常使用的旧哈希表会被清空,而新的哈希表变成日常使用的。

代码语言:c复制
typedef struct dict {
    dictType *type;
    void *privdata;
    // 哈希表
    dictht ht[2];
    in trehashidx;
} dict;

(2)跳跃表。

跳跃表的底层结构类似于一个值 保存了指向其他节点的level数组,而这个level数组的作用就是用来加快访问其他节点的速度。跳跃表的查询效率是比较快的,可以和平衡二叉树相媲美,同时跳跃表相比平衡树的实现更加的简单。

跳跃表的组成结构如下所示。

代码语言:c复制
typedef struct zskiplistNode {
    // level数组
    struct zskiplistLevel {
        // 前进指针
        struct zskiplistNode *forward;
        // 跨度
        unsigned int span;
    } level[];
    // 后退指针
    struct zskiplistNode *backward;
    // 分值
    double score;
    robj *obj;
} zskiplistNode;

2.4 为什么使用字典和跳跃表

面试官:那有序集合为什么要使用字典和跳跃表?

同时使用字典和跳跃表的设计主要是考虑了性能因素,两者都有其效率最高的场景,要高效利用它们来提高Redis性能。

  1. 如果单纯使用字典,查询时的效率很高,可以达到高效的O(1)时间复杂度。但执行类似ZRANGE、ZRNK命令时,效率是比较低的。因为每次排序需要在内存上对字典进行排序一次,这消耗了额外的O(n)内存空间。
  2. 如果单纯使用跳跃表,虽然执行类似ZRANGE、ZRNK命令时的效率高,但查询性能又会从O(1)上升到了O(logN)。

所以Redis内部会对有序集合采用字典和跳跃表两种实现,当使用对应不同场景时,就采用对应的不同数据结构来高效操作有序集合。

2.5 压缩列表

面试官:压缩列表呢?

压缩列表顾名思义作用在于压缩,主要是Redis为了节约内存开发的一种数据结构。一共有三种数据类型使用到了压缩列表。

列表键里如果包含的都是类似小整数、短字符串类型的,会采用压缩列表的底层实现。

代码语言:sh复制
127.0.0.1:6379> rpush number 1 2 3
(integer) 3
127.0.0.1:6379> object encoding number
"ziplist"

哈希键如果只包含少量的键值对,同时键、值都是类似小整数、短字符串类型的,会采用压缩列表的底层实现。

代码语言:sh复制
127.0.0.1:6379> hset msg name JavaGetOffer
(integer) 1
127.0.0.1:6379> hset msg avator 思考的陈
(integer) 1
127.0.0.1:6379> object encoding msg
"ziplist"

有序集合当元素个数小于128个时,内部编码会转换为压缩列表ziplist。

代码语言:sh复制
127.0.0.1:6379> zadd 100run:ranking 13 mike 12 jake 16 tom
(integer) 3
127.0.0.1:6379> object encoding 100run:ranking
"ziplist"

3. Redis数据库

3.1 Redis数据库的理解

面试官:Redis的数据库知道吧?

我们可以把Redis的数据库和MySQL的数据库理解成同一个东西,不同数据库之间都是相互隔离的,在一个数据库中定义的键对其他数据库不可见。例如我们在Redis的数据库1设置键值对,在数据库1可以查询出来,而在数据库2中是查询不出来的。

代码语言:shell复制
# 示例命令
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> set name JavaGetOffer
OK
127.0.0.1:6379[1]> select 2
OK
127.0.0.1:6379[2]> get name
(nil)
127.0.0.1:6379[2]> select 1
OK
127.0.0.1:6379[1]> get name
"JavaGetOffer"

Redis默认会创建16个数据库,在业务上我们可以把不同业务所需键值对存储在不同Redis数据库,来达到根据业务划分不同数据库存储的作用。

代码语言:shell复制
# 查询一共有几个数据库
127.0.0.1:6379> config get databases
1) "databases"
2) "16"

另外Redis数据库主要由这两部分组成:dict字典即键空间、expires字典即过期字典,我们下文会讲到。

3.2 数据库的键空间

面试官:那数据库的键空间呢?

键空间顾名思义是存储键的容器,在Redis上字典存储了数据库中所有的键值对,这个字典也就是键空间。

大家记住不要把字典和Redis提供的哈希对象弄混淆了,前者是Redis的底层数据结构支持,而后者是Redis提供给外部使用的。

键空间的概念图如下,dict字典存储了所有键,每个键的指针指向值的引用地址。

在这里插入图片描述在这里插入图片描述

Redis对键值对的添加、删除、更新、查询操作都是基于键空间的基础上,先从dict字典查询出键,再根据键找到对应值进行操作。

3.3 键过期时间

面试官:一个键要怎么设置过期时间?

可以先设置键值对,后使用EXPIRE命令来设置键的过期时间,过期时间的单位是

代码语言:shell复制
127.0.0.1:6379> set name0 JavaOffer训练营
OK
127.0.0.1:6379> expire name0 66
(integer) 1
127.0.0.1:6379> ttl name0
(integer) 66
127.0.0.1:6379> get name0
"JavaOffer训练营"

另外也可以使用SETEX命令一步到位,同时设置值和过期时间。

代码语言:shell复制
127.0.0.1:6379> setex name 66 JavaGetOffer
OK
127.0.0.1:6379> ttl name
(integer) 66
127.0.0.1:6379> get name
"JavaGetOffer"

大家回答面试官时补充企业实战的具体细节是可以加分的,例如对键值对设置过期时间,可以使用Jedis客户端的setex方法。

代码语言:java复制
    public String setex(String key, int seconds, String value) {
        this.checkIsInMultiOrPipeline();
        this.client.setex(key, seconds, value);
        return this.client.getStatusCodeReply();
    }

3.4 过期字典

面试官:那键的过期时间知道用什么存储吗?

既然所有键使用字典存储起来,那键的过期时间也可以使用字典存储起来,这个字典我们称它为过期字典

因为键空间已经存储了所有的键值对,过期字典没必要再存储一次,所以过期字典的键地址指向的是键空间的指针。而过期字典的值是一个long long类型的整数,代表了过期日期的UNIX时间戳

在这里插入图片描述在这里插入图片描述

4. 内存回收策略

4.1 过期键删除策略

面试官:键的过期删除策略是什么?

过期键删除策略一共有三种:定时删除策略、惰性删除策略、定期删除策略。其中定时删除、定期删除是主动删除,而惰性删除是被动删除。

每一种删除策略都有其优缺点,也适应不同的业务场景。

一、定时删除对内存友好,对CPU不友好。定时删除策略会为设置过期时间的键创建一个定时器,使用定时器可以定时删除过期的键值对,释放出内存;但在大量定时器执行过程中会占用一部分CPU。如果在Redis的内存充沛但CPU非常紧张的业务场景下,此时定时器再执行,无疑会影响Redis的响应时间和吞吐量。

二、惰性删除对CPU友好,对内存不友好,可能会出现内存泄漏。该策略会放任过期的键不管,直到每次获取键,如果发现键过期了,才会释放出键内存。如果在大量键没被访问的业务场景下,Redis内存会大量浪费在已过期的键上。

三、定期删除策略。每隔一段时间检查数据库中一部分的键,删除其中的过期键,该策略可以设置删除操作的执行时长和频率。它的缺点在于确认删除操作的执行时长和频率比较麻烦。

三种过期键删除策略各有优缺点,Reids服务器实际上是采用了惰性删除策略、定期删除策略这两种策略配合使用,让服务器在避免CPU紧张和内存消耗过多之间取得平衡。

4.2 内存淘汰策略

面试官:Redis还有什么策略可以释放内存?

为了节约内存,Reids除了会对过期键进行删除外,还会在内存达到内存上限时进行内存回收,也就是Redis的内存淘汰策略

内存上限可以通过config命令来动态配置。

代码语言:shell复制
127.0.0.1:6379> config set maxmemory 1GB
OK
127.0.0.1:6379> config get maxmemory
1) "maxmemory"
2) "1073741824"

而内存溢出控制策略一共有六种,我们可以通过配置maxmemory-policy参数来进行控制。

  1. noeviction:默认策略不会删除任何键值对,同时会拒绝所有写命令。
  2. volatile-lru:根据LRU最近最少使用算法删除设置了过期时间的键,直到腾出足够的空间。如果没有可删除的键对象,则会回退到noeviction策略。
  3. allkeys-lru:和volatile-lru同样的作用,不过针对的是所有键
  4. allkeys-random:随机删除所有键,直到腾出足够的空间。
  5. volatile-random:随机删除过期键,直到腾出足够的空间。
  6. volatile-ttl:删除最近将要过期的键。看到后缀ttl我们就知道这个策略和过期时间相关。

以下是Redis配置文件提供的六种内存淘汰策略介绍,大家可以参考下。

代码语言:shell复制
# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached. You can select among five behaviors:
#
# volatile-lru -> Evict using approximated LRU among the keys with an expire set.
# allkeys-lru -> Evict any key using approximated LRU.
# volatile-lfu -> Evict using approximated LFU among the keys with an expire set.
# allkeys-lfu -> Evict any key using approximated LFU.
# volatile-random -> Remove a random key among the ones with an expire set.
# allkeys-random -> Remove a random key, any key.
# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
# noeviction -> Don't evict anything, just return an error on write operations.
#
# LRU means Least Recently Used
# LFU means Least Frequently Used
#
# Both LRU, LFU and volatile-ttl are implemented using approximated
# randomized algorithms.
#
# Note: with any of the above policies, Redis will return an error on write
#       operations, when there are no suitable keys for eviction.
#
#       At the date of writing these commands are: set setnx setex append
#       incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
#       sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
#       zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
#       getset mset msetnx exec sort
#
# The default is:
#
# maxmemory-policy noeviction

5. Redis持久化

5.1 持久化概念

面试官:知道Redis持久化吗?

Redis本身是一个基于内存的数据库,它提供了RDB持久化、AOF持久化两种方式,用来将存储在内存中的数据库状态保存到磁盘中。前者是保存了整个Redis数据库状态,而后者是保存了从Redis启动后所有执行的写命令。接下来我们就从这两方面展开。

5.2 生成RDB文件

面试官:你说一说生成RDB文件的命令是什么?

触发RDB持久化过程分为手动触发和自动触发,手动触发的命令有两个,一个是SAVE命令,一个是BGSAVE命令,执行命令后会在根目录生成名为dump.rdb的文件。

大家看下以下手动触发的使用。

代码语言:shell复制
# 手动生成RDB文件指令
127.0.0.1:6379> save
OK
127.0.0.1:6379> bgsave
Background saving started

另外RDB文件是在Redis启动时自动载入,如果把dump.rdb文件删除,重启Redis后会发现原先的数据库状态都不存在了。

代码语言:shell复制
# 初始化
127.0.0.1:6379> set name JavaGetOffer
OK
127.0.0.1:6379> get name
"JavaGetOffer"
127.0.0.1:6379> save
OK

# 重启Redis
127.0.0.1:6379> get name
"JavaGetOffer"

# 删除dump.rdb,重启Redis后name为nil
127.0.0.1:6379> get name
(nil)

5.3 两种命令的选择

面试官:你会在什么场景使用什么命令?

SAVE命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在服务器进程阻塞期间,服务器不能处理其他任何命令请求。

而BGSAVE命令则不进行阻塞,它会派生出一个子进程,然后由子进程负责创建RDB文件,服务器进程继续处理命令请求。可以在上面的指令中看到执行BGSAVE指令后,终端显示Background saving started

所以如果在业务高峰期要使用进行RDB持久化,建议是使用后者,可以防止某些请求丢失了。

5.4 生成AOF文件

面试官:AOF文件生成呢?

AOF文件生成需要在Redis配置文件配置appendonly的属性值。

代码语言:shell复制
appendonly yes

重启Redis执行写命令后,会生成appendonly.aof文件。

也可以在终端手动设置appendonly属性值。

代码语言:shell复制
config set appendonly yes
在这里插入图片描述在这里插入图片描述

6. AOF重写

6.1 AOF概念

面试官:知道AOF文件重写吗?

AOF文件是AOF持久化的产物,AOF持久化通过保存服务器所有执行的写命令来记录数据库状态。而AOF文件重写主要是为了解决AOF文件体积膨胀的问题。

对于一个键值对,AOF旧的文件会保存数十条对该键值对的修改命令,这样浪费了大量内存空间。

而AOF文件重写可以创建一个新的AOF文件来替代现有的AOF文件,新旧两个AOF文件所保存的数据库状态相同,但新AOF文件不会包含任何浪费空间的冗余命令,使得新的AOF文件体积很小。

简单来说,就是新的AOF文件只会保存键值对的最终状态的创建命令

6.2 多条命令记录键值

面试官:照你这么说,只会保存创建命令,那每个键的创建只有一条命令对吧?

如果每个键的创建只有一条命令,在执行命令时可能会造成客户端输入缓冲区溢出。

Redis重写程序在处理列表、哈希表、集合、有序集合这四种可能会带有多个元素的键时,如果元素的数量超过了redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD常量的值,那么重写程序将使用多条命令来记录键的值,而不单单只使用一条命令。

6.3 AOF重写缓冲区

面试官:AOF重写过程中,有新的创建请求进来怎么办?

AOF重写过程中,有新的创建请求进来怎么办?可以把这些新的创建请求写入到一个缓冲区里。

Redis服务器会维护一个AOF重写缓冲区,该缓冲区会在子进程创建新AOF文件期间,记录服务器执行的所有写命令。

等新的AOF文件创建完成,Redis服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾,从而保证两个新旧AOF文件状态一致。

在这里插入图片描述在这里插入图片描述

我是南哥,南就南在Get到你的点赞点赞点赞。

在这里插入图片描述在这里插入图片描述

创作不易,不妨点赞、收藏、关注支持一下,各位的支持就是我创作的最大动力❤️

0 人点赞