Redis(十四)——缓存问题

 1、缓存穿透

(1)问题描述

缓存和数据库中都没有数据。例如利用不存在的key恶意攻击，导致数据库压力过大

(2)解决方案

• 接口层增加参数校验，用户鉴权，id非法拦截。
• 从缓存取不到数据，数据库也没有查到，返回值在缓存设置短时间默认值或者空。
• 布隆过滤器快速判断key是否存在数据库。

2、缓存击穿

(1)问题描述

1个key过期时，访问量巨大

(2)解决方案

• 热点数据永不过期
• 互斥锁，第一个线程访问key的时候就锁住，等查询数据库返回后，把值写到缓存再释放锁，后续请求直接取缓存。

3、缓存雪崩

(1)问题描述

大量key同时过期或者缓存服务器宕机也算雪崩

(2)解决方案

• 热点数据永不过期
• 缓存数据的过期时间设置随机
• 分布式缓存集群，确保高可用，例如redis-cluster

4、缓存和数据库一致性

(1)问题描述

数据库与缓存更新，可能会出现数据不一致的情况。写和读是并发的，无论是「先写数据库再删缓存」还是「先删缓存再写数据库」都可能出现数据不一致的情况。

• 如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。
• 如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。

(2)解决方案

• 先删缓存再写数据库：一般情况用这个就够了。这种操作出现数据不一致的条件是：读缓存时缓存失效，而且并发着有一个写操作，读操作必需在写操作前进入数据库操作，而又要晚于写操作更新缓存。 但实际上写操作会比读操作慢很多，还要锁表，因此满足数据不一致的概率不大。
• 队列+失败重试：写库成功后删除缓存失败，将key发到MQ中消费，失败继续发MQ，直到成功。缺点是对业务代码造成大量入侵。
• 订阅binlog：订阅MySQL的写操作日志，更新redis。