Redis 缓存常见问题以及处理方式

Redis

1.穿透

简单来说就是查询了一个不存在的数据；数据请求查询透到了DB层，但是DB层查询后结果也是空；导致没有生成缓存对应的数据。

处理方式：

1.1 建立空对象的缓存key。但是会增加内存消耗，需要考虑成本问题

1.2 利用布隆过滤器。难保证双写数据一致，无法删除元素；小概率遇到hash碰撞导致误判；极端情况下会导致大量请求同时达到DB层。

2.击穿

访问的key刚好失效导致全部请求打到了DB层，同时如果该key是热key，就有可能导致DB服务宕机。

处理方式

2.1 设置失效期为永不失效

2.2 增加互斥锁，后面的请求都hold住

2.3 设置二级缓存（本地缓存）；无法保证本地缓存的数据是最新的数据；

3.雪崩

在同一时间点大量key失效过期，导致所有请求透到DB层

处理方式

3.1 为预计的热key设置过期时间时增加一个随机时间，防止同时过期

3.2 设置为永久不过期

3.3 保证redis服务的高可用

3.4 使用互斥锁逐步重新创建所有缓存。

3.5 异步任务全量重新创建缓存

4热KEY

业务中被大量访问的key过期导致的击穿后果。

处理方式

4.1同击穿方式处理吧

4.2 拆分热key的构建方式;如果是集群分布需要考虑横向分割（保证每个key落在不同的节点）

5.持久化

深度理解Redis持久化：https://blog.csdn.net/qq_45656077/article/details/129613273

5.1 RDB（Redis Database），快照方式；按照设定值每隔X秒建立快照。分为手动触发和自动触发；每次执行save时会触发；（默认开启）。

利用COW（Copy On Write）写时复制方案达到非阻塞方式实现快照持久化。fork主进程的子进程进行操作，理论上是不会阻塞主进程的，但是如果快照建立的间隔时间太短且内容过大，就会陷入争抢磁盘I/O和fork子进程的问题进而导致主进程阻塞

优点：恢复快，适合大数据模式下的全量恢复

缺点：无法保证数据实时性

5.2 AOF(Append only file)，追加模式；将每次执行的命令追加到日志文件的末尾；先执行命令，后记录日志（默认关闭）

优点：能保证数据的实时性

缺点：大量数据恢复时会很慢，它记录的是每一条执行的命令；恢复时其实也就是按照原来的执行日志重新执行一次。如果写时磁盘压力，写入文件很慢就会导致主进程阻塞。