redis面试题使用场景（redis常用数据结构介绍和业务应用场景分析）

本文目录

• redis常用数据结构介绍和业务应用场景分析
• 面试官：Redis中的缓冲区了解吗-
• 大厂面试题详解：如何用Redis实现分布式锁
• redis如何理解呢，在哪些方面有应用呢
• Redis数据库适合使用于哪些应用场景

redis常用数据结构介绍和业务应用场景分析

redis内置了很多常用数据结构，了解这些数据结构的功能和应用场景能够让我们在需求开发时灵活运用来解决实际问题。

String是redis中最基础的数据结构，你可以把它用作缓存最基础的kv（key-value）类型的缓存(value最大为512MB)，只需要把需要缓存的对象进行string的编解码即可。另外String也可以保存数值类型的数据，就可以来实现计数功能（redi提供了incr等原子操作）

常见应用场景

List列表更多的时候是把它当成队列使用(最大2^32 - 1个元素)，使用入队出队功能，如果来使用它作为各种列表的话，很多时候不具备防重功能在使用的时候不是很方便。

常见应用场景

Set是一种无序不重复的集合，添加删除检查是否存在都是O(1)的时间复杂度。

常见应用场景

hash是一个map结构，可以像存储对象的多个字段一样存储一个key的多类数据。

常见应用场景

redis中的pub/sub可以实现广播功能，类似rocketmq中的broadcast

常见应用场景

除了上述最基本的数据结构外，redis还提供了一些其他的数据结构，有的是需要安装相关redis stack来使用的。

bitmap本质上还是使用的string字符串，不过可以通过bit来进行操作，把这个key的value值想象成bit组成的数组。

常见应用场景

bloomfilter（也叫布隆过滤器）可以理解成一种特殊的set集合，它可以用来判断一个值是否在这个集合中，不过不同于普通的set，它的判断存在一定误判的可能（假阳性），如果bloomfilter判断一个值不在这个集合中，那么一定不在，但是如果判断在，那么有可能不在。

常见应用场景

hyperloglog是一种概率性的去重计数数据结构，可以实现一定精度的去重计数

常见应用场景

geohash可以实现距离计算、距离查询等地理位置相关的功能

常见应用场景

面试官：Redis中的缓冲区了解吗-

hello 大家好，我是七淅（xī）。

Redis 大家肯定不陌生，但在使用层面看不到的地方，就容易被忽略。今天想和大家分享的内容是 Redis 各个缓冲区的作用、溢出的后果及优化方向 。

在开始正文前，想多叨叨几句。不管是 Redis 还是其他中间件，底层很多原理都是相似的，设计思想都是通用的。

大家以后如果在学什么新框架/组件，可以尽量和已经学过的知识点进行联想，这样会更容易理解点的，不至于说死记硬背。

比如现在说到的缓冲区，它的目的是什么呢？

无它，为了性能。

要么缓存数据， 提高响应速度 。比如 My**L 中有个 change buffer

要么担心消费者速度跟不上生产，怕 数据丢失 。所以需要把生产数据先暂存起来。Redis 的缓冲区就是这个作用。

另外，消费者速度跟不上，如果是同步处理的话，那是不是也会拖慢生产者，所以这里其实也是在保证生产者的速度。

可能有的读者会说：扯淡，消费者都跟不上了，生产者再快有什么用？

其实有没有一种可能，生产者根本不关心消费者什么时候用呢？前者是负责把后者需要的东西处理好给它就完事了。生产者很忙，还有其他一大堆数据要处理，不能慢慢等消费者同步消费完才去做其他事情。

好像开头扩展得有点多，我收一收，下面会详细说到。有疑问的小伙伴请上车，七淅正式发车了。

首先 Redis 有什么缓冲区呢？

一共 4 个：

服务器端会给 每个连接的客户端 都设置了一个输入缓冲区。

暂存请求数据。

输入缓冲区会先把客户端发送过来的命令暂存起来，Redis 主线程再从输入缓冲区中读取命令，进行处理。

为了避免客户端和服务器端的请求发送和处理速度不匹配，这点和等下要说的输出缓冲区是一样的。

首先缓冲区是一块固定大小的内存区域，如果要把这个地方填满的话，那 Redis 会直接把客户端连接关闭。

保护自己嘛，你客户端挂了总比我服务端挂了好，服务端一挂就是所有客户端都没用了。

那填满缓冲区就有 2 个情况了：

那么把上述原理对应到 Redis 的场景。

一下子填满的情况可以是往 Redis 里写大量数据，百万千万数量级那种。

另一个情况可以是 Redis 服务端因执行耗时操作，阻塞住了，导致没法消费输入缓冲区数据。

对应上面 2 个溢出场景，优化方向很自然就有了。

一下子填满的情况，是不是可以考虑不要一下子写这么多数据，能否拆下数据（其实一下子写大量数据本身就不合理哈）

另外，是否可以调高缓冲区大小呢？

这个其实是不行的哈，因为没有可以设置的地方，目前服务端默认为每个客户端输入缓冲区分配的大小是 1GB。

那轮到第 2 个溢出场景：两边处理速度不一致。

正常来说，服务端不应该出现长时间阻塞，所以需要看看是什么原因导致的阻塞，解决到就好了。

同输入缓冲区，服务器端也会给 每个连接的客户端 都设置了一个输出缓冲区。

同上，也是暂存请求数据。

这个地方其实我在文章开头说的，生产者不关心消费者什么时候用，只负责把消费者之前请求的东西处理好就完事了。

服务端一般都会和多个客户端连接，加上 redis 网络通信模块是单线程的（即使是新版本支持多线程也一样）

假如没有输出缓冲区会发生什么事呢？

服务端处理了很多客户端 A 的请求，需要经过网络这一耗时操作，返回给客户端 A。在这个过程中，客户端 B 的请求一直得不到服务端处理和响应，这样吞吐量就上不去了。

有了缓冲区之后，至少能解放服务端，让它去处理客户端 B 的请求。

这里也是同输入缓冲区，我就不啰嗦了，溢出的话服务端也会关闭客户端连接。

类似的，不要一下子读大量数据；不持续在线上执行 MONITOR 命令。

而输出缓冲区的大小是可以通过 client-output-buffer-limit 来设置的。

但是一般来说，我们都不用改，因为默认情况就够了，这里了解下就好。

温馨提示下，如果对 Redis 同步/复制不了解的读者，比如不知道全量/增量复制，建议可以看下我这篇文章：一文让你明白Redis主从同步。

下面回到正题哈。

有复制肯定有主从，而主从间的数据复制包括全量复制和增量复制两种。

全量复制是同步所有数据，而增量复制只会把主从库网络断连期间主库收到的命令，同步给从库。

暂存数据。

主节点上会为 每个从节点 都维护一个复制缓冲区。

在全量复制时，主节点在向从节点传输 RDB 文件的同时，会继续接收客户端发送的写命令请求，并保存在复制缓冲区中，等 RDB 文件传输完成后，再发送给从节点去执行。

从节点接收和加载 RDB 较慢，同时主节点接收到了大量的写命令，写命令在复制缓冲区中就会越积越多，最后就会溢出。

一旦溢出，主节点会直接关闭和从节点进行复制操作的连接，导致全量复制失败

可以控制主节点数据量在 2~4GB（仅供参考），这样可以让全量同步执行得更快些，避免复制缓冲区累积过多命令

也可以调整缓冲区大小，还是之前的 client-output-buffer-limit 参数。

比如： config set client-output-buffer-limit slave 512mb 128mb 60

这个是在新增复制用到的缓冲区。

暂存数据。

从节点意外断开连接后重连，可从该缓冲区同步期间没同步到的数据。

不会溢出。（想不到吧.jpg）

该缓冲区本质是一个 固定长度，先进先出的队列 ，默认 1MB。

所以当队列被占满，不是报错，也不像上面几个缓冲区直接关闭连接。而是覆盖最早进入队列的数据。

因此，如果有从节点还没有同步这些旧命令数据，就会导致主从节点重新进行全量复制，而不是增量复制。

调整复制积压缓冲区的大小，参数是： repl_backlog_size

大厂面试题详解：如何用Redis实现分布式锁

说一道常见面试题：

一个很简单的答案就是去使用 Redission 客户端。Redission 中的锁方案就是 Redis 分布式锁得比较完美的详细方案。

那么，Redission 中的锁方案为什么会比较完美呢？

正好，我用 Redis 做分布式锁经验十分丰富，在实际工作中，也 探索 过许多种使用 Redis 做分布式锁的方案，经过了无数血泪教训。

所以，在谈及 Redission 锁为什么比较完美之前，先给大家看看我曾经使用 Redis 做分布式锁是遇到过的问题。

我曾经用 Redis 做分布式锁是想去解决一个用户抢优惠券的问题。这个业务需求是这样的：当用户领完一张优惠券后，优惠券的数量必须相应减一，如果优惠券抢光了，就不允许用户再抢了。

在实现时，先从数据库中先读出优惠券的数量进行判断，当优惠券大于 0，就进行允许领取优惠券，然后，再将优惠券数量减一后，写回数据库。

当时由于请求数量比较多，所以，我们使用了三台服务器去做分流。

这个时候会出现一个问题：

如果其中一台服务器上的 A 应用获取到了优惠券的数量之后，由于处理相关业务逻辑，未及时更新数据库的优惠券数量；在 A 应用处理业务逻辑的时候，另一台服务器上的 B 应用更新了优惠券数量。那么，等 A 应用去更新数据库中优惠券数量时，就会把 B 应用更新的优惠券数量覆盖掉。

看到这里，可能有人比较奇怪，为什么这里不直接使用 **L：

原因是这样做，在没有分布式锁的协调下，优惠券数量可能直接会出现负数。因为当前优惠券数量为 1 的时候，如果两个用户通过两台服务器同时发起抢优惠券的请求，都满足优惠券大于 0 每个条件，然后都执行这条 **L 说了句，结果优惠券数量直接变成 -1 了。

还有人说可以用乐观锁，比如使用如下 **L:

这种方式就在一定几率下，很可能出现数据一直更新不上，导致长时间重试的情况。

所以，经过综合考虑，我们就采用了 Redis 分布式锁，通过互斥的方式，以防止多个客户端同时更新优惠券数量的方案。

当时，我们首先想到的就是使用 Redis 的 setnx 命令，setnx 命令其实就是 set if not exists 的简写。

当 key 设置值成功后，则返回 1，否则就返回 0。所以，这里 setnx 设置成功可以表示成获取到锁，如果失败，则说明已经有锁，可以被视作获取锁失败。

如果想要释放锁，执行任务 del 指令，把 key 删除即可。

利用这个特性，我们就可以让系统在执行优惠券逻辑之前，先去 Redis 中执行 setnx 指令。再根据指令执行结果，去判断是否获取到锁。如果获取到了，就继续执行业务，执行完再使用 del 指令去释放锁。如果没有获取到，就等待一定时间，重新再去获取锁。

乍一看，这一切没什么问题，使用 setnx 指令确实起到了想要的互斥效果。

但是，这是建立在所有运行环境都是正常的情况下的。一旦运行环境出现了异常，问题就出现了。

想一下，持有锁的应用突然崩溃了，或者所在的服务器宕机了，会出现什么情况？

这会造成死锁——持有锁的应用无法释放锁，其他应用根本也没有机会再去获取锁了。这会造成巨大的线上事故，我们要改进方案，解决这个问题。

怎么解决呢？咱们可以看到，造成死锁的根源是，一旦持有锁的应用出现问题，就不会去释放锁。从这个方向思考，可以在 Redis 上给 key 一个过期时间。

这样的话，即使出现问题，key 也会在一段时间后释放，是不是就解决了这个问题呢？实际上，大家也确实是这么做的。

不过，由于 setnx 这个指令本身无法设置超时时间，所以一般会采用两种办法来做这件事：

1、采用 lua 脚本，在使用 setnx 指令之后，再使用 expire 命令去给 key 设置过期时间。

2、直接使用 set(key,value,NX,EX,timeout) 指令，同时设置锁和超时时间。

以上两种方法，使用哪种方式都可以。

释放锁的脚本两种方式都一样，直接调用 Redis 的 del 指令即可。

到目前为止，我们的锁既起到了互斥效果，又不会因为某些持有锁的系统出现问题，导致死锁了。这样就完美了吗？

假设有这样一种情况，如果一个持有锁的应用，其持有的时间超过了我们设定的超时时间会怎样呢？会出现两种情况：

出现第一种情况比较正常。因为你毕竟执行任务超时了，key 被正常清除也是符合逻辑的。

但是最可怕的是第二种情况，发现设置的 key 还存在。这说明什么？说明当前存在的 key，是另外的应用设置的。

这时候如果持有锁超时的应用调用 del 指令去删除锁时，就会把别人设置的锁误删除，这会直接导致系统业务出现问题。

所以，为了解决这个问题，我们需要继续对 Redis 脚本进行改动……毁灭吧，累了……

首先，我们要让应用在获取锁的时候，去设置一个只有应用自己知道的独一无二的值。

通过这个唯一值，系统在释放锁的时候，就能识别出这锁是不是自己设置的。如果是自己设置的，就释放锁，也就是删除 key；如果不是，则什么都不做。

脚本如下：

或者

这里，ARGV 是一个可传入的参数变量，可以传入唯一值。比如一个只有自己知道的 UUID 的值，或者通过雪球算法，生成只有自己持有的唯一 ID。

释放锁的脚本改成这样：

可以看到，从业务角度，无论如何，我们的分布式锁已经可以满足真正的业务需求了。能互斥，不死锁，不会误删除别人的锁，只有自己上的锁，自己可以释放。

一切都是那么美好！！！

可惜，还有个隐患，我们并未排除。这个隐患就是 Redis 自身。

要知道，lua 脚本都是用在 Redis 的单例上的。一旦 Redis 本身出现了问题，我们的分布式锁就没法用了，分布式锁没法用，对业务的正常运行会造成重大影响，这是我们无法接受的。

所以，我们需要把 Redis 搞成高可用的。一般来讲，解决 Redis 高可用的问题，都是使用主从集群。

但是搞主从集群，又会引入新的问题。主要问题在于，Redis 的主从数据同步有延迟。这种延迟会产生一个边界条件：当主机上的 Redis 已经被人建好了锁，但是锁数据还未同步到从机时，主机宕了。随后，从机提升为主机，此时从机上是没有以前主机设置好的锁数据的——锁丢了……丢了……了……

到这里，终于可以介绍 Redission（开源 Redis 客户端）了，我们来看看它怎么是实现 Redis 分布式锁的。

Redission 实现分布式锁的思想很简单，无论是主从集群还是 Redis Cluster 集群，它会对集群中的每个 Redis，挨个去执行设置 Redis 锁的脚本，也就是集群中的每个 Redis 都会包含设置好的锁数据。

我们通过一个例子来介绍一下。

假设 Redis 集群有 5 台机器，同时根据评估，锁的超时时间设置成 10 秒比较合适。

第 1 步，咱们先算出集群总的等待时间，集群总的等待时间是 5 秒（锁的超时时间 10 秒 / 2）。

第 2 步，用 5 秒除以 5 台机器数量，结果是 1 秒。这个 1 秒是连接每台 Redis 可接受的等待时间。

第 3 步，依次连接 5 台 Redis，并执行 lua 脚本设置锁，然后再做判断：

再额外多说一句，在很多业务逻辑里，其实对锁的超时时间是没有需求的。

比如，凌晨批量执行处理的任务，可能需要分布式锁保证任务不会被重复执行。此时，任务要执行多长时间是不明确的。如果设置分布式锁的超时时间在这里，并没有太大意义。但是，不设置超时时间，又会引发死锁问题。

所以，解决这种问题的通用办法是，每个持有锁的客户端都启动一个后台线程，通过执行特定的 lua 脚本，去不断地刷新 Redis 中的 key 超时时间，使得在任务执行完成前，key 不会被清除掉。

脚本如下：

其中，ARGV 是可传入的参数变量，表示持有锁的系统的唯一值，也就是只有持有锁的客户端才能刷新 key 的超时时间。

到此为止，一个完整的分布式锁才算实现完毕。总结实现方案如下：

这个分布式锁满足如下四个条件：

当然，在 Redission 中的脚本，为了保证锁的可重入，又对 lua 脚本做了一定的修改，现在把完整的 lua 脚本贴在下面。

获取锁的 lua 脚本：

对应的刷新锁超时时间的脚本：

对应的释放锁的脚本：

到现在为止，使用 Redis 作为分布式锁的详细方案就写完了。

我既写了一步一坑的坎坷经历，也写明了各个问题和解决问题的细节，希望大家看完能有所收获。

最后再给大家提个醒，使用 Redis 集群做分布式锁，有一定的争议性，还需要大家在实际用的时候，根据现实情况，做出更好的选择和取舍。

***隐藏网址***

redis如何理解呢，在哪些方面有应用呢

您好，这样的：
毫无疑问，Redis开创了一种新的数据存储思路，使用Redis，我们不用在面对功能单调的数据库时，把精力放在如何把大象放进冰箱这样的问题上，而是利用Redis灵活多变的数据结构和数据操作，为不同的大象构建不同的冰箱。希望你喜欢这个比喻。
Redis比较适合的一些应用场景，简单列举在这里，供大家一览：
1.取最新N个数据的操作
比如典型的取你网站的最新文章，通过下面方式，我们可以将最新的5000条评论的ID放在Redis的List集合中，并将超出集合部分从数据库获取
使用LPUSH *****《ID》命令，向list集合中插入数据
插入完成后再用LTRIM ***** 0 5000命令使其永远只保存最近5000个ID
然后我们在客户端获取某一页评论时可以用下面的逻辑（伪代码）
FUNCTION get_latest_comments(start,num_items):
id_list = *****("*****",start,start+num_items-1)
IF id_***** 《 num_items
id_list = **L_DB("SELECT ... ORDER BY time LIMIT ...")
END
RETURN id_list
END
如果你还有不同的筛选维度，比如某个分类的最新N条，那么你可以再建一个按此分类的List，只存ID的话，Redis是非常高效的。
2.排行榜应用，取TOP N操作
这个需求与上面需求的不同之处在于，前面操作以时间为权重，这个是以某个条件为权重，比如按顶的次数排序，这时候就需要我们的sorted set出马了，将你要排序的值设置成sorted set的score，将具体的数据设置成相应的value，每次只需要执行一条ZADD命令即可。
3.需要精准设定过期时间的应用
比如你可以把上面说到的sorted set的score值设置成过期时间的时间戳，那么就可以简单地通过过期时间排序，定时清除过期数据了，不仅是清除Redis中的过期数据，你完全可以把Redis里这个过期时间当成是对数据库中数据的索引，用Redis来找出哪些数据需要过期删除，然后再精准地从数据库中删除相应的记录。
4.计数器应用
Redis的命令都是原子性的，你可以轻松地利用INCR，DECR命令来构建计数器系统。
*****操作，获取某段时间所有数据排重值
这个使用Redis的set数据结构最合适了，只需要不断地将数据往set中扔就行了，set意为集合，所以会自动排重。
6.实时系统，反垃圾系统
通过上面说到的set功能，你可以知道一个终端用户是否进行了某个操作，可以找到其操作的集合并进行分析统计对比等。没有做不到，只有想不到。
*****/Sub构建实时消息系统
Redis的Pub/Sub系统可以构建实时的消息系统，比如很多用Pub/Sub构建的实时聊天系统的例子。
8.构建队列系统
使用list可以构建队列系统，使用sorted set甚至可以构建有优先级的队列系统。
9.缓存
这个不必说了，性能优于Memcached，数据结构更多样化。

Redis数据库适合使用于哪些应用场景

redis开创了一种新的数据存储思路，使用redis，我们不用在面对功能单调的数据库时，把精力放在如何把大象放进冰箱这样的问题上，而是利用redis灵活多变的数据结构和数据操作，为不同的大象构建不同的冰箱。
redis常用数据类型
redis最为常用的数据类型主要有以下五种：
string
hash
list
set
sorted set
在具体描述这几种数据类型之前，我们先通过一张图了解下redis内部内存管理中是如何描述这些不同数据类型的：
首先redis内部使用一个redisobject对象来表示所有的key和value,redisobject最主要的信息如上图所示：type代表一
个value对象具体是何种数据类型，encoding是不同数据类型在redis内部的存储方式，比如：type=string代表value存储的是
一个普通字符串，那么对应的encoding可以是raw或者是int,如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然
前提是这个字符串本身可以用数值表示，比如:"123"
"456"这样的字符串。
这里需要特殊说明一下vm字段，只有打开了redis的虚拟内存功能，此字段才会真正的分配内存，该功能默认是关闭状态的，该功能会在后面具体描述。通过
上图我们可以发现redis使用redisobject来表示所有的key/value数据是比较浪费内存的，当然这些内存管理成本的付出主要也是为了给
redis不同数据类型提供一个统一的管理接口，实际作者也提供了多种方法帮助我们尽量节省内存使用，我们随后会具体讨论。
下面我们先来逐一的分析下这五种数据类型的使用和内部实现方式：
string
常用命令：
set,get,decr,incr,mget 等。
应用场景：
string是最常用的一种数据类型，普通的key/value存储都可以归为此类，这里就不所做解释了。
实现方式：
string在redis内部存储默认就是一个字符串，被redisobject所引用，当遇到incr,decr等操作时会转成数值型进行计算，此时redisobject的encoding字段为int。
hash
常用命令：
hget,hset,hgetall 等。
应用场景：
我们简单举个实例来描述下hash的应用场景，比如我们要存储一个用户信息对象数据，包含以下信息：
用户id为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储，主要有以下2种存储方式：
第一种方式将用户id作为查找key,把其他信息封装成一个对象以序列化的方式存储，这种方式的缺点是，增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护，引入cas等复杂问题。
第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户id+对应属性的名称作为唯一标识来取得对应属性的值，虽然省去了序列化开销和并发问题，但是用户id为重复存储，如果存在大量这样的数据，内存浪费还是非常可观的。
那么redis提供的hash很好的解决了这个问题，redis的hash实际是内部存储的value为一个hashmap，并提供了直接存取这个map成员的接口，如下图：
也就是说，key仍然是用户id,
value是一个map，这个map的key是成员的属性名，value是属性值，这样对数据的修改和存取都可以直接通过其内部map的key(redis里称内部map的key为field),
也就是通过 key(用户id) + field(属性标签)
就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。很好的解决了问题。
这里同时需要注意，redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部map的成员很多，那么涉及到遍历整个内部map的
操作，由于redis单线程模型的缘故，这个遍历操作可能会比较耗时，而另其它客户端的请求完全不响应，这点需要格外注意。
实现方式：
上面已经说到redis
hash对应value内部实际就是一个hashmap，实际这里会有2种不同实现，这个hash的成员比较少时redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的hashmap结构，对应的value
redisobject的encoding为zipmap,当成员数量增大时会自动转成真正的hashmap,此时encoding为ht。
list
常用命令：
lpush,rpush,lpop,rpop,lrange等。
应用场景：
redis
list的应用场景非常多，也是redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用redis的list结构来实现，比较好理解，这里不再重复。
实现方式：
redis
list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
set
常用命令：
sadd,spop,**embers,sunion 等。
应用场景：
redis
set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。
实现方式：
set 的内部实现是一个
value永远为null的hashmap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
sorted set
常用命令：
zadd,zrange,zrem,zcard等
使用场景：
redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted
set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted
set数据结构，比如twitter 的public