可能是最漂亮的Redis面试基础详解-阿里云开发者社区

先赞后看，Java进阶一大半

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

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

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

⭐⭐⭐本文收录在《Java学习/进阶/面试指南》：https://github/JavaSouth

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字符串作为缓冲层对象。

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的值。

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

# 从右边添加
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集合存储用户兴趣标签，再使用交集命令来查询。

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进行排序的。

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值，如代码所示。

        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());
        }

    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时使用。当迁移完成后，原先日常使用的旧哈希表会被清空，而新的哈希表变成日常使用的。

typedef struct dict {
   
    dictType *type;
    void *privdata;
    // 哈希表
    dictht ht[2];
    in trehashidx;
} dict;

（2）跳跃表。

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

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

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

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

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

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

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

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

2.5 压缩列表

面试官：压缩列表呢？

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

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

127.0.0.1:6379> rpush number 1 2 3
(integer) 3
127.0.0.1:6379> object encoding number
"ziplist"

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

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。

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中是查询不出来的。

# 示例命令
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数据库，来达到根据业务划分不同数据库存储的作用。

# 查询一共有几个数据库
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命令来设置键的过期时间，过期时间的单位是秒。

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命令一步到位，同时设置值和过期时间。

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方法。

    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命令来动态配置。

127.0.0.1:6379> config set maxmemory 1GB
OK
127.0.0.1:6379> config get maxmemory
1) "maxmemory"
2) "1073741824"

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

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

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

# 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的文件。

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

# 手动生成RDB文件指令
127.0.0.1:6379> save
OK
127.0.0.1:6379> bgsave
Background saving started

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

# 初始化
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的属性值。

appendonly yes

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

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

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文件状态一致。

在这里插入图片描述

⭐⭐⭐本文收录在《Java学习/进阶/面试指南》：https://github/JavaSouth

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

在这里插入图片描述

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

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

1. Redis快的秘密

2. Redis数据类型

2.1 Redis五大基本数据类型

2.2 有序集合业务场景

2.3 有序集合数据结构

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

2.5 压缩列表

3. Redis数据库

3.1 Redis数据库的理解

3.2 数据库的键空间

3.3 键过期时间

3.4 过期字典

4. 内存回收策略

4.1 过期键删除策略

4.2 内存淘汰策略

5. Redis持久化

5.1 持久化概念

5.2 生成RDB文件

5.3 两种命令的选择

5.4 生成AOF文件

6. AOF重写

6.1 AOF概念

6.2 多条命令记录键值

6.3 AOF重写缓冲区

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

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

1. Redis快的秘密

2. Redis数据类型

2.1 Redis五大基本数据类型

2.2 有序集合业务场景

2.3 有序集合数据结构

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

2.5 压缩列表

3. Redis数据库

3.1 Redis数据库的理解

3.2 数据库的键空间

3.3 键过期时间

3.4 过期字典

4. 内存回收策略

4.1 过期键删除策略

4.2 内存淘汰策略

5. Redis持久化

5.1 持久化概念

5.2 生成RDB文件

5.3 两种命令的选择

5.4 生成AOF文件

6. AOF重写

6.1 AOF概念

6.2 多条命令记录键值

6.3 AOF重写缓冲区

热门文章

最新文章

相关课程

相关电子书

相关实验场景