【Redis】八股文必背_redis集群八股

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

Redis键的过期

1. 设置过期时间的命令

2. 过期时间设置原则

• 热点数据不设置过期时间，可以避免缓存击穿问题
• 设置的过期时间时随机值，避免大量key同时过期，导致缓存雪崩

3. Redis处理过期键策略

• 惰性删除： 客户端访问key时，检查是否过期，过期则删除
• 定期删除： 服务端将设置了过期时间的key放到独立字典中，定期进行扫描。扫描逻辑：
  • 随机选择部分key（20）
  • 删除过期key
  • 若过期比例超过25%则重复操作

4. Redis缓存淘汰策略

LRU和LFU的算法代码见这里
当写入数据将导致超出maxmemory限制时，Redis会采用maxmemory-policy所指定的策略进行数据淘汰。该策略包含如下八种。

前缀含义：

• volatile:从设置了过期时间的键中淘汰数据
• allkeys:从所有的键中淘汰数据

LRU与LFU：

• LRU最近最少访问删除策略，非热点数据在偶尔访问后，一段时间内不会被淘汰。
• LFU最近最不经常使用删除策略，访问次数最少会被删除，如果多个数据访问数据相同，则这些数据根据LRU策略删除

Redis的线程

从 Redis 的 v1.0 到 v6.0 版本之前，Redis 的核心网络模型一直是一个典型的单 Reactor 模型。Redis v6.0 才改造成多线程模式。

Redis的主要瓶颈是内存和网络带宽，而非CPU。6.0引入多线程解决网络IO问题。

1. 版本变更中的多线程

2. Redis为什么快

• 单线程处理命令避免上下文切换和线程竞争带来的开销
• 数据存储在内存
• c语言本身性能高
• IO多路复用技术，实现高吞吐的网络IO UNIX IO五种模型

3. Redis核心为什么使用单线程

• 避免上下文切换
• 避免同步机制带来开销
• 简单可维护

如何设计分布式锁

• set key value nx ex seconds 原子性地赋值和设置过期时间
• Redisson框架

更多

双写一致问题

• 先删缓存后更数据库
• 先更新缓存后更新数据库
• 先更数据库后删缓存
• 先更新数据库后更新缓存
• 延时双删

1. 删除和更新缓存的比较

• 删除：
  • 优点：操作简单
  • 缺点：下次读取时需要重新从数据库取
• 更新：
  • 优点：数据变化更新及时
  • 缺点：写多读少的场景性能差。

2. 先删缓存后更数据库

在A线程删缓存和更新数据库期间，其他线程查询并更新缓存后，会造成数据库和缓存不一致的情况。

3. 先更新缓存后更新数据库

A线程更新缓存后若数据库更新失败，会造成数据库和缓存不一致的情况。一般需要重试，一般通过异步方式进行

4. 先更数据库，后删除/更新缓存

• 在 A线程更新数据库到删除/更新缓存期间，其它线程查询到的数据是历史缓存数据，与数据库不一致。
• 若A线程删/更新缓存失败，则从A更新数据库后，缓存和数据库就一直不一致。

5. 延时双删

1. 若B线程在A第一次删缓存和更数据库期间查询数据库，并在A更新数据和延时删除缓存之间更新了缓存，那么在B更新缓存和A延时删缓存的中间时刻发生数据不一致。
2. 若是B线程更新缓存在A延时删除缓存之后发生，则同样发生了数据不一致。这说明延时时间设置不合理。

延时时间的设置：

• 设置时间过大可能导致情况1发生
• 设置时间过小可能导致情况2发生
• 需要根据业务场景合理估计设置时间

6. 如何强一致

• 对单key使用分布式锁，将缓存操作和数据库操作放到一个锁中，会影响性能，需要注意失败处理和锁的释放
• 放弃缓存
• 单key串行化读写，相同key的操作加入等待队列（类似于加锁）

如何使用布隆过滤器

布隆过滤器使用bit位存储数据。占用空间小。

可以用于拦截不存在的数据，有概率拦截到存在的数据。

其它

1. Redis各种数据结构原理

见【Redis】数据结构与对象

2. 持久化

见【Redis】RDB与AOF持久化

3. 高可用

见【Redis】Redis高可用

3. 大key问题

什么是大key？：

value值占用内存较大

有什么影响：

• 网络传输内容大，占用带宽，服务端和客户端的读取耗时增加
• 可能是热key，频繁读取影响性能
• 大key用del删除时，会阻塞线程
• 可能带来分布式系统中的数据倾斜，资源利用率不平衡
• 在集群中，数据迁移困难（migrate 命令是通过 dump 和 restore 和 del 三个命令组合成原子命令完成，如果是存在 bigkey 的话，可能会因为大 value 的原因导致迁移失败，而且较慢的 migrate 会阻塞 Redis，影响 Redis 服务）

如何产生：

一般是因为业务涉及不合理，没有预计value动态增长

• 一直往value里塞数据，没有删除或者限制机制
• 数据没有进行分片，将大key变为小key

如何排查：

• 利用redis-cli bigkeys命令，在线扫描（不会阻塞）
• 利用redis-rdb-toos，离线分析RDB持久化文件，实时性差，但是完全离线对性能无影响

如何解决：

• 删除： 先用scan渐进式查找key，（用keys * 会阻塞）
  • 低于4.0版本，除了string类型，其他类型都可以每次用del删除一部分
  • 高于4.0版本，可以使用unlink直接异步删除
• 压缩与拆分：
  • string类型：难以拆分，可以序列化、压缩。但是会增加额外耗时
  • hash类型 ：字段拆分，将一个对象分为多个部分，读取时可以使用multiget事务读取
  • list、set类型：可以通过计算分片到不同的集群节点上

1. Redis大key 问题
2. Scan命令
3. 如何使用bigkeys等命令

todo

• RedLock
• 选举算法
• Redisson原理
• 事务、广播、消息队列
• 监控、问题处理

参考

• Java面试宝典
• Redis多线程网络模型全面揭秘
• Reactor模式介绍
• Redis（十三）：Redis多线程
• Redis6系列1-线程模型（单线程OR多线程）
• Redis6.0多线程模型总结
• redis缓存为什么要延时双删
• 分布式锁中的王者方案 - Redisson
• 七种方案！探讨Redis分布式锁的正确使用姿势
• Redis一些基本问题整理