redis常见面试题

南易_站长

阅读量：6698

redis常见面试题

## 1 redis 简介

> 简单来说 redis 就是一个数据库，不过与传统数据库不同的是 redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向。另外，redis 也经常用来做分布式锁。redis 提供了多种数据类型来支持不同的业务场景。除此之外，redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

## 2 为什么要用 redis/为什么要用缓存

主要从“高性能”和“高并发”这两点来看待这个问题。

### 2.1 高性能：

> 假如用户第一次访问数据库中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据存在数缓存中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

![16eba44c96d051be.webp](http://fengzq.cn/upload/16eba44c96d051be_2020_10_0_14_9.webp)

### 2.2 高并发：

> 直接操作缓存能够承受的请求是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。

![16eba45803ad6c85.webp](http://fengzq.cn/upload/16eba45803ad6c85_2020_10_0_14_10.webp)

## 3 为什么要用 redis 而不用 map/guava 做缓存?

缓存分为**本地缓存**和**分布式缓存**。以 Java 为例，使用自带的 map 或者 guava 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性。

使用 redis 或 memcached 之类的称为分布式缓存，在多实例的情况下，各实例共用一份缓存数据，缓存具有一致性。缺点是需要保持 redis 或 memcached服务的高可用，整个程序架构上较为复杂。

## 4 redis 和 memcached 的区别

1. **redis支持更丰富的数据类型（支持更复杂的应用场景）**：Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。memcache支持简单的数据类型，String。
2. **Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用,而Memecache把数据全部存在内存之中**。
3. 集群模式：memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 **redis 目前是原生支持 cluster 模式的**.
4. **Memcached是多线程，非阻塞IO复用的网络模型；Redis使用单线程的多路 IO 复用模型**。
![16eba47ad5cef0c2.webp](http://fengzq.cn/upload/16eba47ad5cef0c2_2020_10_0_14_10.webp)

## 5 redis 常见数据结构以及使用场景分析

### 5.1 String

**常用命令**: set,get,decr,incr,mget 等。

String数据结构是简单的key-value类型，value其实不仅可以是String，也可以是数字。  
常规key-value缓存应用； <br**> 常规计数：微博数，粉丝数等。

### 5.2 Hash

**常用命令**： hget,hset,hgetall 等。

hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值。 比如我们可以 hash 数据结构来存储用户信息，商品信息等等。

### 5.3 List

**常用命令**: lpush,rpush,lpop,rpop,lrange等

list 就是链表，Redis list 的应用场景非常多，也是Redis最重要的数据结构之一，比如微博的关注列表，粉丝列表，消息列表等功能都可以用Redis的 list 结构来实现。

Redis list 的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。

另外可以通过 lrange 命令，就是从某个元素开始读取多少个元素，可以基于 list 实现分页查询，这个很棒的一个功能，基于 redis 实现简单的高性能分页，可以做类似微博那种下拉不断分页的东西（一页一页的往下走），性能高。

### 5.4 Set

**常用命令**： sadd,spop,smembers,sunion 等 set 对外提供的功能与list类似是一个列表的功能，特殊之处在于 set 是可以自动排重的。

当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。可以基于 set 轻易实现交集、并集、差集的操作。

比如：在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis可以非常方便的实现如共同关注、共同粉丝、共同喜好等功能。这个过程也就是求交集的过程，具体命令如下：

### 5.5 Sorted Set

**常用命令**： zadd,zrange,zrem,zcard等

和set相比，sorted set增加了一个权重参数score，使得集合中的元素能够按score进行有序排列。

举例： 在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息（可以理解为按消息维度的消息排行榜）等信息，适合使用 Redis 中的 Sorted Set 结构进行存储。

## 6 Redis五种数据结构的底层原理

[juejin.im/post/684490…](https://juejin.im/post/6844903869391044622)  
[juejin.im/post/684490…](https://juejin.im/post/6844903856313368589)

## 7 redis 设置过期时间

Redis中有个设置时间过期的功能，即对存储在 redis 数据库中的值可以设置一个过期时间。作为一个缓存数据库，这是非常实用的。如我们一般项目中的 token 或者一些登录信息，尤其是短信验证码都是有时间限制的，按照传统的数据库处理方式，一般都是自己判断过期，这样无疑会严重影响项目性能。

我们 set key 的时候，都可以给一个 expire time，就是过期时间，通过过期时间我们可以指定这个 key 可以存活的时间。

如果假设你设置了一批 key 只能存活1个小时，那么接下来1小时后，redis是怎么对这批key进行删除的？

**定期删除+惰性删除**。

* **定期删除**：redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。注意这里是随机抽取的。为什么要随机呢？你想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载！
* **惰性删除** ：定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。这就是所谓的惰性删除

但是仅仅通过设置过期时间还是有问题的。我们想一下：如果定期删除漏掉了很多过期key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期key堆积在内存里，导致redis内存块耗尽了。怎么解决这个问题呢？ redis 内存淘汰机制。

## 8 Redis怎么知道过期了？

[Redis之过期 key 底层逻辑](https://www.jianshu.com/p/40defc2edb33)

## 9 redis 内存淘汰机制(MySQL里有2000w数据，Redis中只存20w的数据，如何保证Redis中的数据都是热点数据?)

* 限定Redis占用的内存，根据自身数据淘汰策略，淘汰冷数据，把热数据加载到内存；
* 计算一下20w数据大约占用的内存，然后设置一下Redis内存限制即可。

### 10 redis 提供 6种数据淘汰策略：

* volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
* volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
* volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
* allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
* allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
* no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。

4.0版本后增加以下两种：

* volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
* allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key

## 11 redis 持久化机制(怎么保证 redis 挂掉之后再重启数据可以进行恢复)

### 11.1 快照（snapshotting）持久化（RDB）

Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性能），还可以将快照留在原地以便重启服务器的时候使用。

快照持久化是Redis默认采用的持久化方式，在redis.conf配置文件中默认有此下配置：

```
save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
复制代码
```

### 11.2 AOF（append-only file）持久化

与快照持久化相比，AOF持久化 的实时性更好，因此已成为主流的持久化方案。默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数开启：

```
appendonly yes
复制代码
```

开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof。

在Redis的配置文件中存在三种不同的 AOF 持久化方式，它们分别是：

```
appendfsync always    #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
appendfsync everysec  #每秒钟同步一次，显示地将多个写命令同步到硬盘
appendfsync no        #让操作系统决定何时进行同步
复制代码
```

为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec选项 ，让Redis每秒同步一次AOF文件，Redis性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

### 11.3 Redis 4.0 对于持久化机制的优化

Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）。

如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式，可读性较差。

### 11.4 补充内容：AOF 重写

AOF重写可以产生一个新的AOF文件，这个新的AOF文件和原有的AOF文件所保存的数据库状态一样，但体积更小。

AOF重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有AOF文件进行任何读入、分析或者写入操作。

在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新AOF文件期间，记录服务器执行的所有写命令。当子进程完成创建新AOF文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾，使得新旧两个AOF文件所保存的数据库状态一致。最后，服务器用新的AOF文件替换旧的AOF文件，以此来完成AOF文件重写操作

## 12 redis 事务

Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。

在传统的关系式数据库中，常常用 ACID 性质来检验事务功能的可靠性和安全性。在 Redis 中，事务总是具有原子性（Atomicity）、一致性（Consistency）和隔离性（Isolation），并且当 Redis 运行在某种特定的持久化模式下时，事务也具有持久性（Durability）。

## 13 缓存雪崩和缓存穿透问题解决方案

### 13.1 缓存雪崩

![16eba6ffe62bd125.webp](http://fengzq.cn/upload/16eba6ffe62bd125_2020_10_0_14_11.webp)

* 简介：缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。
* 解决办法
    * 事前：尽量保证整个 redis 集群的高可用性，发现机器宕机尽快补上。选择合适的内存淘汰策略。
    * 事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL崩掉
    * 事后：利用 redis 持久化机制保存的数据尽快恢复缓存
    * 缓存雪崩

### 13.2 缓存穿透

* 简介：一般是黑客故意去请求缓存中不存在的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。
* 解决办法
    
    > 有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

## 14 如何解决 Redis 的并发竞争 Key 问题

所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作，但是最后执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同！

推荐一种方案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）。（如果不存在 Redis 的并发竞争 Key 问题，不要使用分布式锁，这样会影响性能）

**Redis分布式锁的实现原理**：

* [juejin.im/post/684490…](https://juejin.im/post/6844903717641142285)
* [juejin.im/post/684490…](https://juejin.im/post/6844903465181773831)

**基于zookeeper临时有序节点可以实现的分布式锁**。大致思想为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。完成业务流程后，删除对应的子节点释放锁。

在实践中，当然是从以可靠性为主。所以**首推Zookeeper**。

## 15 如何保证缓存与数据库双写时的数据一致性?

你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？

一般来说，就是如果你的系统不是严格要求缓存+数据库必须一致性的话，缓存可以稍微的跟数据库偶尔有不一致的情况，最好不要做这个方案，读请求和写请求串行化，串到一个内存队列里去，这样就可以保证一定不会出现不一致的情况

串行化之后，就会导致系统的吞吐量会大幅度的降低，用比正常情况下多几倍的机器去支撑线上的一个请求。

## 16 Redis中数据库默认是多少个db即作用？

Redis默认支持16个数据库，可以通过配置databases来修改这一数字。客户端与Redis建立连接后会自动选择0号数据库，不过可以随时使用select命令更换数据库。

Redis支持多个数据库，并且每个数据库是隔离的不能共享，并且基于单机才有，如果是集群就没有数据库的概念。

## 17 Redis如何实现主从复制？自己数据同步机制？

### 17.1 优势：

* 高可用
* 分担主压力

### 17.2 注意：

* slave设置只读

### 17.3 主从复制实现：

* '创建6379和6380配置文件'
* redis.conf:6379为默认配置文件，作为Master服务器配置；
* redis_6380.conf:6380为同步配置**，作为slave服务器配置；
* '配置slaveof同步命令'
* 在Slave对应的conf配置文件中，添加以下内容：slaveof 127.0.0.1 6379

### 17.4 数据同步步骤：

1. Slave服务器连接到Master服务器；
2. Slave服务器发送同步(SYCN)命令；
3. Master服务器备份数据库到文件；
4. Master服务器把备份文件传输给Slave服务器；
5. Slave服务器把备份文件数据导入到数据库中。

## 18 什么是redis集群？

redis集群、分片、分布式redis

![16ebb1231fd271ee.webp](http://fengzq.cn/upload/16ebb1231fd271ee_2020_10_0_14_11.webp)

### 18.1 集群方案：

* redis cluster 官方提供的集群方案；
* codis 豌豆荚技术团队；
* tweproxy， Twisted技术团队

### 18.2 redis cluster的原理？

* 基于分片来完成
    * 集群是将你的数据拆分到多个redis实例的过程；
    * 可以使用很多电脑的内存总和来支持更大的数据库；
    * 没有分片，你就被局限于单机能支持的内存容量。
* redis将所有能放置数据的地方创建了 **16384 个哈希槽**；
* 如果设置集群的话，就可以为每个实例分配哈希槽：
    * 192.168.1.20 【0-5000】
    * 192.168.1.21 【5001-10000】
    * 192.168.1.22 【10001-16384】
* **实现可靠性：投票容错机制**
    * (1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.
    * (2)节点的fail是通过集群中超过半数的节点检测失效时才生效.
    * (3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

![16ebb1317ed18421.webp](http://fengzq.cn/upload/16ebb1317ed18421_2020_10_0_14_11.webp)

* 以后想要在redis中写值时：set k1 123
    
    > 将k1通过crc16的算法，将k1转换成一个数字，然后将该数字和16384求余，如果得到的余数3000，那么就将该值写入到192.168.1.20实例中。

## 19 如何基于redis实现发布和订阅？以及发布订阅和消息队列的区别？

### 19.1 发布订阅模型：

![16eba671263b2069.webp](http://fengzq.cn/upload/16eba671263b2069_2020_10_0_14_12.webp)

### 19.2 消息队列模型：

![16eba678cc12afc5.webp](http://fengzq.cn/upload/16eba678cc12afc5_2020_10_0_14_12.webp)

### 19.3 区别：

发布订阅模型是所有的订阅者都能收到消息(相当于在群里发个消息)，而消息队列模型是只有一个成员能收到消息(相当于抢红包)。

## 推荐阅读

* [《吊打面试官》系列-Redis常见面试题（带答案）](https://juejin.im/post/6844903993240453134##)
* [500万日订单下的高可用拼购系统，到底暗藏了什么“独门秘籍”?](https://mp.weixin.qq.com/s/XXgnq10iIFGVOZY58LfYLQ)

## 参考

* [剖析面试最常见问题之Redis](https://xiaozhuanlan.com/topic/6845397012#sectionredis-6)

转载自作者：Zenwish74229  
原文链接：https://juejin.im/post/6844904007836631054  
来源：掘金  
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

表情

登录

注册

南易_站长

阅读量：6698

redis常见面试题

评论