JAVA八股文面试必会-分布式框架-4.1 分布式缓存

吉迪恩

已于 2024-09-11 11:07:31 修改

阅读量2k

点赞数 43

分类专栏： Java八股文面试文章标签：面试职场和发展缓存开发语言 redis

于 2024-06-10 11:06:07 首次发布

本文链接：https://blog.csdn.net/lky20011016/article/details/139574551

版权

Java八股文面试专栏收录该内容

21 篇文章 1 订阅

订阅专栏

01- 你们项目中哪里用到了Redis ?

在我们的项目中很多地方都用到了Redis , Redis在我们的项目中主要有三个作用 :

使用Redis做热点数据缓存/接口数据缓存
使用Redis存储一些业务数据 , 例如 : 验证码 , 用户信息 , 用户行为数据 , 数据计算结果 , 排行榜数据等
使用Redis实现分布式锁 , 解决并发环境下的资源竞争问题

02- Redis的常用数据类型有哪些 ?

Redis中的数据类型有很多 , 例如 :

string：最基本的数据类型，二进制安全的字符串，最大512M
list：按照添加顺序保持顺序的字符串列表
set：无序的字符串集合，不存在重复的元素
sorted set：已排序的字符串集合
hash：key-value对的一种集合
bitmap：更细化的一种操作，以bit为单位
hyperlog：基于概率的数据结构
Geo : 地理位置类型

常用的就是string ,list , set , zset 和hash

03- Redis的数据持久化策略有哪些 ?

Redis 提供了两种方式，实现数据的持久化到硬盘。

RDB 持久化(全量)，是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
AOF持久化(增量)，以日志的形式记录服务器所处理的每一个写、删除操作

RDB和AOF一起使用, 在Redis4.0版本支持混合持久化方式 ( 设置 aof-use-rdb-preamble yes )

RDB和AOF区别 ?

备份方式不同 , RDB是定时对整个内存的数据做快照 , AOF采用的是日志追加方案, 记录的是一个个指令
RDB因为是定时备份 , 二次备份之间如果出现了系统宕机可能会导致两次备份之间的数据丢失 , AOF采用日志追加, 可以配置刷盘策略如果是always会记录每个指令 , 不会出现数据丢失, 如果是every second , 可能会导致1秒以内的数据丢失 , 如果是no ,可能会丢失大量数据
因为RDB备份 , 只保存内存数据 , 所以备份文件的体积比较小 , AOF存储的是指令, 所以备份文件的体积比较大
在宕机恢复的时候RDB只需要将备份的数据读取到内存即可, 恢复数据比较快, AOF需要将备份文件中的指令一个个重新执行一遍 , 恢复效率比较低

04- Redis的数据过期策略有哪些 ?

惰性删除 ：只会在取出 key 的时候才对数据进行过期检查。这样对 CPU 最友好，但是可能会造成太多过期 key 没有被删除。

数据到达过期时间，不做处理。等下次访问该数据时，我们需要判断

如果未过期，返回数据
发现已过期，删除，返回nil

定期删除 ：每隔一段时间抽取一批 key 执行删除过期 key 操作。并且，Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。

默认情况下 Redis 定期检查的频率是每秒扫描 10 次，用于定期清除过期键。当然此值还可以通过配置文件进行设置，在 redis.conf 中修改配置“hz”即可，默认的值为hz 10

定期删除的扫描并不是遍历所有的键值对，这样的话比较费时且太消耗系统资源。Redis 服务器采用的是随机抽取形式，每次从过期字典中，取出 20 个键进行过期检测，过期字典中存储的是所有设置了过期时间的键值对。如果这批随机检查的数据中有 25% 的比例过期，那么会再抽取 20 个随机键值进行检测和删除，并且会循环执行这个流程，直到抽取的这批数据中过期键值小于 25%，此次检测才算完成

Redis 服务器为了保证过期删除策略不会导致线程卡死，会给过期扫描增加了最大执行时间为 25ms

定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有千秋，所以 Redis 采用的是 定期删除+惰性删除

05- Redis的数据淘汰策略有哪些 ?

Redis 提供三类八种数据淘汰策略：

第一类 : 淘汰易失数据(具有过期时间的数据)

volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-lfu（least frequently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最不经常使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

第二类 : 淘汰全库数据

allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）
allkeys-lfu（least frequently used）：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

第三类 : 不淘汰

no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！

06- 你们使用Redis是单点还是集群 ? 哪种集群 ?

我们Redis使用的是Cluster集群 , 三主六从 , 一个主节点挂载二个从节点 , 保证数据安全和集群的可用性

07- Redis集群有哪些方案, 知道嘛 ?

我所了解的Redis集群方案

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

08- 什么是 Redis 主从同步？

Redis 的主从同步(replication)机制，允许 Slave 从 Master 那里，通过网络传输拷贝到完整的数据备份，从而达到主从机制。

主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据。一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

主从数据同步主要分二个阶段 :

第一阶段 : 全量复制阶段

slave节点请求增量同步
master节点判断replid，发现不一致，拒绝增量同步
master将完整内存数据生成RDB，发送RDB到slave
slave清空本地数据，加载master的RDB

第二阶段 : 增量复制阶段

master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
slave执行接收到的命令，保持与master之间的同步

09- Redis分片集群中数据是怎么存储和读取的 ?

Redis集群采用的算法是哈希槽分区算法。Redis集群中有16384个哈希槽（槽的范围是 0 -16383，哈希槽），将不同的哈希槽分布在不同的Redis节点上面进行管理，也就是说每个Redis节点只负责一部分的哈希槽。在对数据进行操作的时候，集群会对使用CRC16算法对key进行计算并对16384取模（slot = CRC16(key)%16383），得到的结果就是 Key-Value 所放入的槽，通过这个值，去找到对应的槽所对应的Redis节点，然后直接到这个对应的节点上进行存取操作

10- 你们用过Redis的事务吗 ? 事务的命令有哪些 ?

Redis 作为 NoSQL 数据库也同样提供了事务机制。在 Redis 中有四个事物相关指令

MULTI : 开启事物
EXEC : 提交事物
DISCARD : 回滚事务
WATCH : 监控事物

我们在开发过程中基本上没有用到过Redis的事务 , 如果需要保证多个操作的原子性, 经常会使用Lua脚本 , 把多个Redis操作封装到一个lua脚本中, 作为一个指令发送给Redis服务器执行

11- Redis的内存用完了会发生什么？

如果达到设置的上限，Redis 的写命令会返回错误信息（但是读命令还可以正常返回）
也可以配置内存淘汰机制，当 Redis 达到内存上限时会冲刷掉旧的内容 , 释放出内存空间

12- Redis和Mysql如何保证数据⼀致?

保证数据⼀致的方式有很多 , 需要根据不同的情况选择对应的解决方案, 我所了解的方案主要有三种 :

同步双写机制

先更新Mysql，再更新Redis，这个时候如果更新Redis失败，可能仍然不⼀致

删除缓存重新加载机制

先删除Redis缓存数据，再更新Mysql，再次查询的时候在将数据添加到缓存中

这种⽅案能解决1 ⽅案的问题，但是仍然会出现数据不⼀致的问题
⽐如线程1删除了 Redis缓存数据，还没有来得及更新Mysql，此时另外⼀个查询再查询，那么就会把Mysql中⽼数据⼜查到 Redis中

延迟双删机制

先删除Redis缓存数据再更新Mysql，再次查询的时候在将数据添加到缓存中 , 这种方案可能仍然会有数据 , 这个时候我们可以在删除之后稍微延迟(1-2S)时间 , 再将数据删除 , 再次查询的时候进行缓存 , 这个时候就能保持一致了 , 至于延迟删除我们可以使用定时任务延迟, 也可以使用消息中间件延迟删除

对于一致性要求不高的场景, 也可以使用MQ异步同步, 保证数据的最终一致性 , 不需要直接删除

我们项目中会根据业务情况 , 使用不同的方案来解决Redis和Mysql的一致性问题 :

对于一些一致性要求不高的场景 , 不做处理

例如 : 用户行为数据 , 我们没有做一致性保证 , 因为就算不一致产生的影响也很小

对于时效性数据 , 设置过期时间

例如 : 接口缓存数据 , 我们会设置缓存的过期时间为 60S , 那么可能会出现60S之内的数据不一致, 60S后缓存过期, 重新从数据库加载就一致了

对于一致性要求比较高但是时效性要求不那么高的场景 , 使用MQ不断发送消息完成数据同步直到成功为止

例如 : 首页广告数据 , 首页推荐数据

数据库数据发生修改----> 发送消息到MQ -----> 接收消息更新缓存

对于一致性和时效性要求都比较高的场景 , 使用延迟双删机制

13- 什么是缓存穿透 ? 怎么解决 ?

缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。

有哪些解决办法

最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等
缓存无效 key , 如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间 , 尽量将无效的 key 的过期时间设置短一点比如 1 分钟
布隆过滤器 , 提前将数据库中存在的数据加载到布隆过滤器 , 当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程
布隆过滤器底层是一个字符串，也可以理解为是一个二进制数字组成的数组，数组每个成员用 0或1表示。

每一位默认值为 0，表示否定。1表示肯定。

程序启动时或者每一次产生新数据，就会根据运单ID 在布隆过滤器里面做三次 hash映射然后对数组长度取余，就得到一个数组下标，反复执行3次，将这3次计算后得到的下标位置改成 1，就代表这条运单在布隆过滤器中留下影子了。

当下次查询请求过来后，相同的运单 ID，经过之前存入时使用的的三次hash 算法，得到 3个下标，如果都为 1，就代表这笔运单 ID 是存在的，可以去查询，如果有一个为 0，就直接拒绝返回。

当然在极端情况下，也可能出现 hash 碰撞，恰好在查询时，执行3次计算后，映射的底层数组下标位置已经被别的数据改成1了，就导致误判率，不过这样没关系，我们将绝大部分无效请求拦截在外，就够了

14- 什么是缓存击穿 ? 怎么解决 ?

某个热点 key，在缓存过期的一瞬间，同时有大量的请求打进来，由于此时缓存过期了，所以请求最终都会走到数据库，造成瞬时数据库请求量大、压力骤增，导致数据库存在被打挂的风险

有哪些解决办法

1. 加互斥锁。当热点key过期后，大量的请求涌入时，只有第一个请求能获取锁并阻塞，此时该请求查询数据库，并将查询结果写入redis后释放锁。后续的请求直接走缓存

2. 设置缓存不过期或者后台有线程一直给热点数据续期

15- 什么是缓存雪崩 ? 怎么解决

缓存雪崩是指缓存在同一时间大面积的失效，后面的请求都直接落到了数据库上，造成数据库短时间内承受大量请求。这就好比雪崩一样，摧枯拉朽之势，数据库的压力可想而知，可能直接就被这么多请求弄宕机了。

有哪些解决办法

采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用
限流，避免同时处理大量的请求

设置不同的失效时间比如随机设置缓存的失效时间
针对热点数据设置缓存永不失效

16- 数据库有1000万数据 ,Redis只能缓存20w数据, 如何保证Redis中的数据都是热点数据 ?

配置Redis的内容淘汰策略为LFU算法 , 这样会把使用频率较低的数据淘汰掉 , 留下的数据都是热点数据

17- Redis分布式锁如何实现 ?

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

只有在key不存在的情况下，将键key的值设置为value。如果key已经存在，则SETNX命令不做任何操作。

这个命令的返回值如下。

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

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

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

当然我们在使用分布式锁的时候也不能这么简单, 会考虑到一些实际场景下的问题 , 例如 :

死锁问题

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

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

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

锁超时问题

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

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

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

归一问题

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

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

为了解决只有加锁的线程才能进行相应的解锁操作的问题，那么，我们就需要将加锁和解锁操作绑定到同一个线程中，可以使用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);   
     }
 }
}

可重入问题

当一个线程成功设置了锁标志位后，其他的线程再设置锁标志位时，就会返回失败。

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

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

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

实现可重入锁最简单的方式就是使用计数器 , 加锁成功之后计数器 + 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);      
         }
     }
 }
}