四、过期数据的删除策略

1、设置过期时间

上面设置了过期时间，那么如何对这些过期的数据进行删除呢？

惰性删除
- 在根据key进行读数据的时候进行检查，看看是否过期；对CPU友好，但是如果有大量的该删除数据未删除对内存是很崩溃的。
定期删除
- 每隔一段时间抽取一批 key 执行删除过期 key 的操作。对内存很友好，但是过长频率的操作可能会对CPU带来很大的影响，所以Redis通过限制删除操作的执行时长和频率来减少对CPU消耗的影响。
Redis 采用的是 定期删除+惰性删除

我们通过定期删除和惰性删除，还有可能会漏掉大量过期的key未删除的情况，导致内存堆积大量无用的key。所以我们引入了淘汰机制来解决这个问题。

Redis 提供 6 种数据淘汰策略：

Redis 4又引入了两种淘汰机制：

保证 Redis 挂掉之后再重启数据可以进行恢复
Redis支持两种不同的持久化操作：RDB（快照） 和 AOF（追加文件）

（默认）RDB
- 通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。在指定的时间间隔内将内存中的数据集快照写入磁盘，恢复时是将快照文件直接读到内存里。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能）。
- 快照持久化是 Redis 默认采用的持久化方式
（主流）AOF
- AOF 持久化的实时性更好
- 每执行一条会更改Redis数据的命令，Redis就会将该命令写入磁盘中的AOF文件中。Redis启动之初会读取该文件重新构建数据。也就是说Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
- 为了兼顾数据和写入性能，用户可以让 Redis 每秒同步一次 AOF 文件（如果是每次修改发生时都会写入AOF文件，那么会严重降低Redis的速度），Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。

什么是缓存击穿
- 就是说大量的key根本不存在于缓存中，导致大量的请求打到了数据库上，导致数据库崩溃。
解决办法
- （治标不治本）缓存无效key：就是说如果缓存和数据库都查不到，那么久生成一个key，并设置过期时间写入到Redis里面。如果有大量无效的请求，那么会导致 Redis 中缓存大量无效的 key。
- 布隆过滤器：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。
  PS：盗用大神一张图（假装看不见，哈哈哈）：
  - 使用布隆过滤器可能会小概率的误判（因为他是根据哈希进行存值，又是根据hash来判断此值是否存在，那么这就有一个问题，我们在核心卷1中知道不同的字符串，他们的hash值有可能是会相同的，所以会带来小概率的误判情况）

什么是缓存雪崩
- 就是大量的key同时失效，那么大量的请求过来以后，发现对应的key失效，那就回造成数据库短时间内承受大量的请求，搞崩数据库。称为 缓存雪崩 。
- 一种场景就是：有一些被大量访问数据（热点缓存）在某一时刻大面积失效，导致对应的请求直接落到了数据库上。
解决办法
- 如果Redis不可用的话，我们可以尝试搭建集群来解决不可用的情况
- 针对缓存失效，我们可以给缓存设置不同的失效时间。
- 针对缓存失效，暴力的解决办法就是设置缓存不失效（不推荐）

三种读写策略

⭐（常见） Cache Aside Pattern（旁路缓存模式）
- 大体思路就是先更新数据库，再删除缓存 。
- 抛出问题：有一个问题就是DB更新成功，但是缓存删除失败
  - 增加cache更新重试机制（常用） ：如果 cache 服务当前不可用导致缓存删除失败的话，我们就隔一段时间进行重试，重试次数可以自己定。
  - 缓存失效时间变短（不推荐）
Read/Write Through Pattern（读写穿透）
- 同步更新 cache 和 DB
Write Behind Pattern（异步缓存写入）
- 只更新缓存，不直接更新 DB，而是改为异步批量的方式来更新 DB

基于 Redis 实现分布式锁的方式名叫 Redlock

（PS：又是盗图的一刻）
在这里插入图片描述