Redis经典面试题

文章目录

• 1、Redis适用场景
• 2、redis为什么执行这么快？
• 3、Redis的线程模型
• • Redis版本在6.0之前都是单线程
  • Redis6.x多线程的实现机制
  • Redis6.x默认是否开启了多线程
• 4、Redis常见的数据类型
• 5、缓存穿透、击穿、雪崩
• • 1、缓存穿透
  • 2、缓存雪崩
  • 3、缓存击穿
• 6、Redis的数据持久化策略
• 7、Redis集群有哪些方案
• 8、Redis分布式锁如何实现
• • 你的项目中哪里用到了分布式锁
  • 分布式锁具体场景分析
  • • 1、死锁问题
    • 2、锁超时问题
    • 3、归一问题
    • 4、可重入问题
    • 5、阻塞与非阻塞问题
• 9、Redis的过期策略与内存淘汰策略

---

1、Redis适用场景

• 会话缓存（Session Cache）
  最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。
• 队列
  Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作。
• 适用bitmap构建布隆过滤器。
• 排行榜/计数器
  Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。
• 发布/订阅，Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。

2、redis为什么执行这么快？

• 纯内存操作：Redis将所有数据存储在内存中，这意味着对数据的读写操作直接在内存中运行，而内存的访问速度远远高于磁盘。这种设计使得Redis能够已接近硬件极限的速度处理数据读写
• 单线程模型：Redis使用单线程模型来处理客户端请求。这可能听起来效率不高，但是实际上，这种设计避免了多线程频繁切换和过度竞争带来的性能开销。Redis每个请求的执行时间都是很短的，因此单线程下，也能处理大量的并发请求
• I/O多路复用：Redis使用了I/O多路复用技术，可以在单线程的环境下同时监听多个客户端连接，只有当有网络事件（如用户发送一个请求）发生的时候才会进行实际的I/O操作。这样有效的利用了CPU资源，减少了无谓的等待
• 高效数据结构：Redis提供了多种高效的数据结构，如哈希表、有序集合等。这些数据结构的实现都经过了优化，使得Redis在处理这些数据结构的操作是非常高效的

---

3、Redis的线程模型

Redis版本在6.0之前都是单线程

所有的客户端的请求处理、命令执行以及数据读写操作都是在一个主线程中完成得。这种设计目的就是为了防止多线程环境下的锁竞争和上下文切换所带来的性能开销，这样保证在高并发场景下的性能

Redis6.0 引入多线程主要是为了提高网络 IO 读写性能（Redis 的瓶颈并不在 CPU，而在内存和网络。）。但是 Redis 的多线程只是在网络数据的读写这类耗时操作上使用了，对于指令的执行过程仍然是在主线程来处理 。因此不需要担心线程安全问题。

Redis6.x多线程的实现机制

• 主线程负责接收建立连接请求，获取 Socket 放入全局等待读处理队列。
• 主线程处理完读事件之后，通过 RR（Round Robin）将这些连接分配给这些 IO 线程。
• 主线程阻塞等待 IO 线程读取 Socket 完毕。
• 主线程通过单线程的方式执行请求命令，请求数据读取并解析完成，但并不执行。
• 主线程阻塞等待 IO 线程将数据回写 Socket 完毕。
• 解除绑定，清空等待队列。
  该设计有如下特点
• IO 线程要么同时在读 socket，要么同时在写，不会同时读或写。
• IO 线程只负责读写 socket 解析命令，不负责命令处理。

Redis6.x默认是否开启了多线程

Redis6.0 的多线程默认是禁用的，只使用主线程。

如需开启需要修改 redis 配置文件 redis.conf

io-threads-do-reads yes

开启多线程后，还需要设置线程数，否则是不生效的。同样需要修改 redis 配置文件 redis.conf

io-threads 4 #官网建议4核的机器建议设置为2或3个线程，8核的建议设置为6个线程

4、Redis常见的数据类型

• 字符串（String）：最简单的数据类型，可以包含任意数据，如文本、二进制数据等。常见的使用场景是存储Session信息、存储缓存信息、存储整数信息，可以使用incr实现整数+1，使用decr实现整数-1。
• 列表（List）：有序的字符串元素集合，支持双端进行插入和删除操作，可以用作队列或栈。
• 哈希（Hash）：用于存储对象，类似于关联数组。每个哈希可以包含字段和与之相关联的值。常见使用场景是存储Session信息、存储商品的购物车，购物车非常适用于哈希字典表示，使用人员唯一编号作为字典的key，value值可以存储商品的id和数量等信息、存储详情页等信息。
• 集合（Set）：一个无序并唯一的键值集合。它常见的使用场景是是关注功能，比如关注我的人和我关注的人，使用集合存储，可以保证人员不重复。
• 有序集合（Sorted Set）：使用zset表示，相当于Set集合类型多了一个排序属性score（分值）。。它常见的使用场景是可以用来存储排名信息，关注列表功能，这样就可以根据关注实现排序展示。

5、缓存穿透、击穿、雪崩

1、缓存穿透

缓存穿透 是指缓存和数据库中都没有的数据，而用户不断发起请求，造成数据库的压力倍增的情况。
例如 ：发起为id值为 -1 的数据或 id 为特别大不存在的数据。

解决方案：

• 接口层增加校验，比如用户鉴权校验，参数做校验 比如：id 做基础校验，id <=0的直接拦截。
• 对于像ID为负数的非法请求直接过滤掉，采用布隆过滤器(Bloom Filter)。
• 针对在数据库中找不到记录的，我们仍然将该空数据存入缓存中，当然一般会设置一个较短的过期时间。

2、缓存雪崩

缓存服务器宕机或者大量缓存集中某个时间段失效，导致请求全部去到数据库，造成数据库压力倍增的情况，这个是针对多个key而言 。

解决方案：

• 实现缓存高可用，通过redis cluster将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题。
• 批量往Redis存数据的时候，把每个Key的失效时间都加个随机值。

3、缓存击穿

redis过期后的一瞬间，有大量用户请求同一个缓存数据，导致这些请求都去请求数据库，造成数据库压力倍增的情，针对一个key而言。

• 缓存击穿与缓存雪崩的区别是这里针对的是某一热门key缓存，而雪崩针对的是大量缓存的集中失效
  
  解决方案

• 设置热点数据永远不过期。

• 添加互斥锁，保证同一时刻只有一个线程可以访问数据库。

6、Redis的数据持久化策略

• RDB 持久化(全量)，是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
• AOF持久化(增量)，以日志的形式记录服务器所处理的每一个写、删除操作
• RDB和AOF一起使用, 在Redis4.0版本支持混合持久化方式 ( 设置 aof-use-rdb-preamble yes )

---

7、Redis集群有哪些方案

• 主从复制集群 : 读写分离, 一主多从 , 解决高并发读的问题
• 哨兵集群 : 主从集群的结构之上 , 加入了哨兵用于监控集群状态 , 主节点出现故障, 执行主从切换 , 解决高可用问题
• Cluster分片集群 : 多主多从 , 解决高并发写的问题, 以及海量数据存储问题 , 每个主节点存储一部分集群数据

8、Redis分布式锁如何实现

Redis分布式锁主要依靠一个SETNX指令实现的 , 这条命令的含义就是"SET if Not Exists"，即不存在的时候才会设置值。

• 命令在设置成功时返回1。
• 命令在设置失败时返回0。

假设此时有线程A和线程B同时访问临界区代码，假设线程A首先执行了SETNX命令，并返回结果1，继续向下执行。而此时线程B再次执行SETNX命令时，返回的结果为0，则线程B不能继续向下执行。只有当线程A执行DELETE命令将设置的锁状态删除时，线程B才会成功执行SETNX命令设置加锁状态后继续向下执行。

你的项目中哪里用到了分布式锁

在我最近做的一个项目中 , 我们在任务调度的时候使用了分布式锁

早期我们在进行定时任务的时候我们采用的是SpringTask实现的 , 在集群部署的情况下, 多个节点的定时任务会同时执行 , 造成重复调度 , 影响运算结果, 浪费系统资源

这里为了防止这种情况的发送, 我们使用Redis实现分布式锁对任务进行调度管理 , 防止重复任务执行

后期因为我们系统中的任务越来越多 , 执行规则也比较多 , 而且单节点执行效率有一定的限制 , 所以定时任务就切换成了XXL-JOB , 系统中就没有再使用分布式锁了

分布式锁具体场景分析

1、死锁问题

在使用分布式锁的时候, 如果因为一些原因导致系统宕机, 锁资源没有被释放, 就会产生死锁

解决的方案 : 上锁的时候设置锁的超时时间

Boolean isLocked = stringRedisTemplate.opsForValue().setIfAbsent(PRODUCT_ID, "binghe", 30, TimeUnit.SECONDS);

2、锁超时问题

如果业务执行需要的时间, 超过的锁的超时时间 , 这个时候业务还没有执行完成, 锁就已经自动被删除了

其他请求就能获取锁, 操作这个资源 , 这个时候就会出现并发问题 , 解决的方案 :

• 引入Redis的watch dog机制, 自动为锁续期
• 开启子线程 , 每隔20S运行一次, 重新设置锁的超时时间

3、归一问题

如果一个线程获取了分布式锁, 但是这个线程业务没有执行完成之前 , 锁被其他的线程删掉了 , 又会出现线程并发问题 , 这个时候就需要考虑归一化问题

就是一个线程执行了加锁操作后，后续必须由这个线程执行解锁操作，加锁和解锁操作由同一个线程来完成。

为了解决只有加锁的线程才能进行相应的解锁操作的问题，那么，我们就需要将加锁和解锁操作绑定到同一个线程中，可以使用ThreadLocal来解决这个问题 , 加锁的时候生成唯一标识保存到ThreadLocal , 并且设置到锁的值中 , 释放锁的时候, 判断线程中的唯一标识和锁的唯一标识是否相同, 只有相同才会释放

public class RedisLockImpl implements RedisLock{
 @Autowired
 private StringRedisTemplate stringRedisTemplate;
​
 private ThreadLocal<String> threadLocal = new ThreadLocal<String>();
​
 @Override
 public boolean tryLock(String key, long timeout, TimeUnit unit){
     String uuid = UUID.randomUUID().toString();
     threadLocal.set(uuid);
     return stringRedisTemplate.opsForValue().setIfAbsent(key, uuid, timeout, unit);
 }
 @Override
 public void releaseLock(String key){
     //当前线程中绑定的uuid与Redis中的uuid相同时，再执行删除锁的操作
     if(threadLocal.get().equals(stringRedisTemplate.opsForValue().get(key))){
       stringRedisTemplate.delete(key);   
     }
 }
}

4、可重入问题

还有一种场景就是在一个业务中, 有个操作都需要获取到锁, 这个时候第二个操作就无法获取锁了 , 操作会失败

例如 : 下单业务中, 扣减商品库存会给商品加锁, 增加商品销量也需要给商品加锁 , 这个时候需要获取二次锁

第二次获取商品锁就会失败 , 这就需要我们的分布式锁能够实现可重入。

实现可重入锁最简单的方式就是使用计数器 , 加锁成功之后计数器 + 1 , 取消锁之后计数器 -1 , 计数器减为0 , 真正从Redis删除锁

public class RedisLockImpl implements RedisLock{
 @Autowired
 private StringRedisTemplate stringRedisTemplate;
​
 private ThreadLocal<String> threadLocal = new ThreadLocal<String>();
​
 private ThreadLocal<Integer> threadLocalInteger = new ThreadLocal<Integer>();
​
 @Override
 public boolean tryLock(String key, long timeout, TimeUnit unit){
     Boolean isLocked = false;
     if(threadLocal.get() == null){
         String uuid = UUID.randomUUID().toString();
      threadLocal.set(uuid);
         isLocked = stringRedisTemplate.opsForValue().setIfAbsent(key, uuid, timeout, unit);
     }else{
         isLocked = true;   
     }
     //加锁成功后将计数器加1
     if(isLocked){
         Integer count = threadLocalInteger.get() == null ? 0 : threadLocalInteger.get();
         threadLocalInteger.set(count++);
     }
     return isLocked;
 }
​
 @Override
 public void releaseLock(String key){
     //当前线程中绑定的uuid与Redis中的uuid相同时，再执行删除锁的操作
     if(threadLocal.get().equals(stringRedisTemplate.opsForValue().get(key))){
         Integer count = threadLocalInteger.get();
         //计数器减为0时释放锁
         if(count == null || --count <= 0){
           stringRedisTemplate.delete(key);      
         }
     }
 }
}

5、阻塞与非阻塞问题

在使用分布式锁的时候 , 如果当前需要操作的资源已经加了锁, 这个时候会获取锁失败, 直接向用户返回失败信息 , 用户的体验非常不好 , 所以我们在实现分布式锁的时候, 我们可以将后续的请求进行阻塞，直到当前请求释放锁后，再唤醒阻塞的请求获得分布式锁来执行方法。

具体的实现就是参考自旋锁的思想, 获取锁失败自选获取锁, 直到成功为止 , 当然为了防止多条线程自旋带来的系统资料消耗, 可以设置一个自旋的超时时间 , 超过时间之后, 自动终止线程 , 返回失败信息

9、Redis的过期策略与内存淘汰策略

参考大佬文章：Redis的过期策略与内存淘汰策略