# 缓存

# 缓存异常

数据一致要求：

读写缓存
对于在缓存进行修改后，写回到数据库有两种策略：

只读缓存：如果有新增数据直接写回数据库；删改时将缓存数据标记为无效，则发生数据缺失而直接去数据库中的数据读入缓存。

新增数据
数据直接写入到数据库中，不对缓存做修改。（符合缓存中没有数据，数据库是最新的。是数据一致的）

修改/删除数据
需要保证原子性，不然会发生数据不一致：

解决方法
重试机制：把要删除或更新的数据存放到消息队列中。如果没有成功删除或者更新数据库值时，可以从消息队列中重新读取，再次尝试更新。如果重试一定次数后仍不成功，向业务层发送报错信息。如果成功删除或更新数据库值后，将该数据从消息队列中移除。

多线程情况下删除数据的问题

先删除缓存，再删除数据库。
A 线程删除缓存但没来得及更新数据库，B 线程读取数据发现数据缺失，去数据库中读取。
导致 B 线程读取到了旧值，它还会把旧值放回到缓存中，让其他线程读取到旧值。
A 线程继续修改数据库。数据库中的值和缓存中不一致。
解决方法：延迟双删。A 线程删除缓存和数据库后 sleep 一段时间。在这段时间里让 B 线程完成读取旧值并填充回缓存。之后再次删除缓存一次。这样其他线程请求会发现值缺失而去访问数据库并把新值存到缓存中。
先删除数据库，再删除缓存。
A 线程删除数据库但没来得及删除缓存， B 线程读取数据从缓存中拿到旧值。
该问题影响不大，A 线程也会在短时间内删除缓存中的内容。读到旧值的数量不会很多。

指大量请求无法在缓存中处理，这些请求会发送到数据库中，导致数据库层压力激增。

原因一
缓存中有大量数据同时过期，导致大量请求无法被处理。
解决方法：

避免给大量数据设置相同的过期时间
如果业务要求某些数据同时失效，可以单独使用 EXPIRE 给数据设置过期时间，设置时增加一个小量级随机数如 1 到 3 分钟。这样在保证过期时间相近的同时避免同时失效。
服务降级
对于不同数据采用不同的处理方式：
- 业务访问非核心数据，暂时停止从缓存中查询。直接返回预定义信息、空值、错误信息；
- 业务访问核心数据，允许查询缓存。缓存未命中继续通过数据库读取。

原因二
Redis 缓存实例故障宕机。
解决方法：

在业务系统里实现服务熔断或请求限流机制
- 熔断（业务影响大）
  监测 Redis 所在机器和数据库的负载指标，当发现缓存实例宕机，数据库负载激增则启动熔断机制。暂停业务对缓存接口的访问，不把请求发给缓存实例而直接返回。等到实例恢复服务后再允许请求发送到缓存系统。
- 请求限流
  在 Redis 实例宕机后，业务中控制每秒进入的请求数，防止请求过多发送到数据库。
事前预防
- 高可用集群通过主从节点构造高可用集群。如果缓存主节点宕机，从节点可以切换为主节点。

对某热点数据的请求无法在缓存中处理，发送到后端导致数据库层压力激增。经常发生在热点数据过期失效时。

解决方法
对于访问特别频繁的热点数据不设置过期时间。

要访问的数据既不在缓存中也不在数据库中。这种情况一般发生在业务层出现误操作或者遭受恶意攻击。当缓存和数据库中数据被误删除，或者专门恶意持续访问数据库中没有的数据会发生缓存穿透。

解决方法