Redis
更新: 2/8/2025 字数: 0 字 时长: 0 分钟
使用场景1
引入
我看你做的项目中，都用到了redis，你在最近的项目中哪些场景使用了redis呢？🤔
缓存、分布式锁、消息队列、延迟队列……
缓存
口诀
穿透无中生有key，布隆过滤null隔离。
缓存击穿过期key,锁与非期解难题。
雪崩大量过期key，过期时间要随机。
面试必考三兄弟，可用限流来保底。
引出
缓存三兄弟（穿透、击穿、雪崩）、双写一致、持久化、数据过期策略，数据淘汰策略
缓存穿透
# 一个get请求:
api/news/getByld/1
查询一个不存在的数据，mysql查询不到数据也不会直接写入缓存，就会导致每次请求都查数据库
解决方案一：缓存空数据
缓存空数据，查询返回的数据为空，仍把这个空结果进行缓存
{key:1,value:null}
优点：简单
缺点：消耗内存，可能会发生不一致的问题
解决方案二：布隆过滤器
优点：内存占用较少，没有多余key
缺点：实现复杂，存在误判
布隆过滤器
布隆过滤器主要是用于检索一个元素是否在一个集合中。我们当时使用的是redisson实现的布隆过滤器。
它的底层主要是先去初始化一个比较大数组，里面存放的二进制0或1。在一开始都是0，当一个key来了之后经过3次hash计算，模于数组长度找到数据的下标然后把数组中原来的0改为1，这样的话，三个数组的位置就能标明一个key的存在。查找的过程也是一样的。
当然是有缺点的，布隆过滤器有可能会产生一定的误判，我们一般可以设置这个误判率，大概不会超过5%，其实这个误判是必然存在的，要不就得增加数组的长度，其实已经算是很划分了，5%以内的误判率一般的项目也能接受，不至于高并发下压倒数据库。
缓存击穿
给某一个key设置了过期时间，当key过期的时候，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB压垮
解决方案一：互斥锁
强一致、性能差
解决方案二：逻辑过期
高可用、性能优、不能保证数据绝对一致
IMPORTANT
缓存击穿的意思是对于设置了过期时间的key，缓存在某个时间点过期的时候，恰好这时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把DB压垮。
解决方案有两种方式：
第一可以使用互斥锁：当缓存失效时，不立即去loaddb，先使用如Redis的setnx去设置一个互斥锁，当操作成功返回时再进行load db的操作并回设缓存，否则重试get缓存的方法
第二种方案可以设置当前key逻辑过期，大概是思路如下：
①：在设置key的时候，设置一个过期时间字段一块存入缓存中，不给当前key设置过期时间
②：当查询的时候，从redis取出数据后判断时间是否过期
③：如果过期则开通另外一个线程进行数据同步，当前线程正常返回数据，这个数据不是最新
当然两种方案各有利弊：
如果选择数据的强一致性，建议使用分布式锁的方案，性能上可能没那么高，锁需要等，也有可能产生死锁的问题
如果选择key的逻辑删除，则优先考虑的高可用性，性能比较高，但是数据同步这块做不到强一致。
缓存雪崩
在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。
解决方案
- 给不同的Key的TTL添加随机值
- 利用Redis集群提高服务的可用性 =>哨兵模式、集群模式
- 给缓存业务添加降级限流策略 =>ngxin或spring cloud gateway
- 给业务添加多级缓存 =>Guava或Caffeine
IMPORTANT
缓存雪崩意思是设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多key，击穿是某一个key缓存。
解决方案主要是可以将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
分布式锁
引出
setnx、redisson
消息队列、延迟队列
引出
何种数据类型
使用场景2
引入
redis做为缓存，mysql的数据如何与redis进行同步呢?
双写一致性
一定、一定、一定要设置前提，先介绍自己的业务背景
双写一致性：当修改了数据库的数据也要同时更新缓存的数据，缓存和数据库的数据要保持一致
读操作：缓存命中，直接返回；缓存未命中查询数据库，写入缓存，设定超时时间
写操作：延迟双删
一致性要求高
允许延迟一致
总结
