redis缓存

缓存穿透

查询一个不存在的数据，mysql查询不到数据，也不会直接写入缓存，就会导致每次请求都查数据库。

解决方式一：缓存空数据，查询返回的数据为空，仍把这个空结果进行缓存

优点：简单
缺点：消耗内存，存在对于key，可能会发生不一致的问题，数据已经更新了，缓存数据还没有更新

解决方式二：布隆过滤器

优点：内存占用较少，没有多余key
缺点：实现复杂，存在误判

布隆过滤器：

bitmap（位图）：相当于是一个已（bit）位为单位的数组，数据中每个单元只能存储二进制数0或1
作用：布隆过滤器可以用于检索一个元素是否在一个集合中
存储数据：
id为1数据，通过多个hash函数获取hash值，根据hash值计算数组对应位置，把对应位置值改为1
查询数据：
使用相同hash函数获取hash值，判断对应位置是否都为1

布隆过滤器实现方案：

redisson
guava


误判率：数组越小，误判率就越大。数组越大，误判率就越小，但是同时带来了更多的内存消耗

缓存击穿

给某一个key设置了过期时间，当key过期的时候，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB压垮

解决方案一：互斥锁，分布式锁，强一致，性能差

解决方案二：逻辑过期，高可用，性能优，不能保证数据绝对一致

缓存雪崩

在同一时间段大量的缓存key同时失效或者redis服务宕机，导致大量请求到达数据库，给数据库带来巨大压力。

解决方案一：给不同的Key的TTL添加随机值

缓存雪崩意思是设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多key，击穿是某一个key缓存。
解决方案主要是可以将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

解决方案二：利用Redis集群提高服务的可用性

哨兵模式、集群模式

解决方案三：给缓存业务添加降级限流策略

nginx或spring cloud gateway
降级可做为系统的保底策略，适用于穿透、击穿、雪崩

解决方案四：给业务添加多级缓存

Guava或Caffeine

双写一致性

当修改了数据库的数据也要同时更新缓存的数据，缓存和数据库的数据要保持一致。

存在问题：先删除缓存，还是先修改数据库都存在问题

解决方案一：延迟双删

解决方案二：分布式锁

解决方案三：异步通知保证数据的最终一致性

解决方案四：基于Canal的异步通知

Redis持久化

RDB

RDB全称是Redis Database Backup file(redis 数据备份文件），也被叫做Redis数据快照，就是把内存中的所有都记录到磁盘中，当redis实例故障重启后，从磁盘读取快照文件，恢复数据

RDB的执行原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。
fork采用的是copy-on-write技术：
当主进程执行读操作时，访问共享内存；
当主进程执行写操作时，则会拷贝一份数据，执行写操作。

AOF

AOF全称为Append Only File（追加文件），Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

AOF的命令记录的频率也可以通过redis.conf文件来配：


因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

Redis数据删除策略

Redis对数据设置数据的有效时间，数据过期以后，就需要将数据从内存中删除掉。可以按照不同的规则进行删除，这种删除规则就被称之为数据的删除策略（数据过期策略）。

惰性删除

设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们再删掉它，反之返回该key

优点 ：对CPU友好，只会在使用该key时才会进行过期检查，对于很多没有过期的key不用浪费时间进行过期检查
缺点 ：对内存不友好，如果一个key已经过期，但是一直没有使用，那么该key就会一直存在内存中，内存永远不会释放

定期删除

每隔一段时间，我们就对一些key进行检查，删除里面过期的key(从一定数量的数据库中取出一定数量的随机key进行检查，并删除其中的过期key)

定期清理有两种模式：
SLOW模式是定时任务，执行频率默认为10hz，每次耗时不超过25ms，以通过修改配置文件redis.conf 的hz 选项来调整这个次数
FAST模式执行频率不固定，但两次执行间隔不低于2ms，每次耗时不超过1ms

优点：可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除，也能有效释放过期键占用的内存。
缺点：难以确定删除操作执行的时长和频率。
Redis的过期删除策略：惰性删除 + 定期删除两种策略进行配合使用

数据淘汰策略

当Redis中的内存不够用时，此时在向Redis中添加新的key，那么Redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。
Redis支持8种不同策略来选择要删除的key：
noeviction： 不淘汰任何key，但是内存满时不允许写入新数据，默认就是这种策略。

volatile-ttl： 对设置了TTL的key，比较key的剩余TTL值，TTL越小越先被淘汰
allkeys-random：对全体key ，随机进行淘汰。
volatile-random：对设置了TTL的key ，随机进行淘汰。
allkeys-lru： 对全体key，基于LRU算法进行淘汰
volatile-lru： 对设置了TTL的key，基于LRU算法进行淘汰
allkeys-lfu： 对全体key，基于LFU算法进行淘汰
volatile-lfu： 对设置了TTL的key，基于LFU算法进行淘汰

LRU（Least Recently Used）最近最少使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
key1是在3s之前访问的, key2是在9s之前访问的，删除的就是key2
LFU（Least Frequently Used）最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。
key1最近5s访问了4次, key2最近5s访问了9次， 删除的就是key1

使用建议

优先使用 allkeys-lru 策略。充分利用 LRU 算法的优势，把最近最常访问的数据留在缓存中。如果业务有明显的冷热数据区分，建议使用。
如果业务中数据访问频率差别不大，没有明显冷热数据区分，建议使用 allkeys-random，随机选择淘汰。
如果业务中有置顶的需求，可以使用 volatile-lru 策略，同时置顶数据不设置过期时间，这些数据就一直不被删除，会淘汰其他设置过期时间的数据。
如果业务中有短时高频访问的数据，可以使用 allkeys-lfu 或 volatile-lfu 策略。