Redis基础--缓存问题3+1

缓存穿透、缓存雪崩、缓存击穿

缓存与数据库数据一致性

缓存穿透

大多数互联网应用，使用缓存的方式如下：

1. 当业务系统发起某一个查询请求时，首先判断缓存中是否有该数据；
2. 如果缓存中存在，则直接返回数据；
3. 如果缓存中不存在，则再查询数据库，返回数据，将数据存入缓存。

缓存穿透：业务系统要查询的数据根本就存在！当业务系统发起查询时，按照上述流程，首先会前往缓存中查询，由于缓存中不存在，然后再前往数据库中查询。由于该数据压根就不存在，因此数据库也返回空。这就是缓存穿透。业务系统访问压根就不存在的数据，就称为缓存穿透。

危害

如果存在海量请求查询压根就不存在的数据，那么这些海量请求都会落到数据库中，数据库压力剧增，可能会导致系统崩溃（你要知道，目前业务系统中最脆弱的就是IO，稍微来点压力它就会崩溃，所以我们要想种种办法保护它）。

发生原因:

• 代码逻辑问题；
• 恶意攻击。

解决方法:

1、缓存空对象。将数据库查询结果为空的key也存储在缓存中。当后续又出现该key的查询请求时，缓存直接返回null，而无需查询数据库。

缓存空对象存在两个问题：

• 空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。
• 缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

2、布隆过滤器（BloomFilter）。需要在缓存之前再加一道屏障，里面存储目前数据库中存在的所有key。

当业务系统有查询请求的时候，首先去BloomFilter中查询该key是否存在。若不存在，则说明数据库中也不存在该数据，因此缓存都不要查了，直接返回null。若存在，则继续执行后续的流程，先前往缓存中查询，缓存中没有的话再前往数据库中的查询。

这种方法适用于数据命中不高，数据相对固定实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。

选择：对于空数据的key各不相同、key重复请求概率低的场景而言，应该选择第二种方案。而对于空数据的key数量有限、key重复请求概率较高的场景而言，应该选择第一种方案。

缓存雪崩

如果缓存因某种原因发生了宕机，那么原本被缓存抵挡的海量查询请求就会像疯了一样涌向数据库。此时数据库如果抵挡不了这巨大的压力，它就会崩溃。这就是缓存雪崩。

如何避免：

1、使用集群架构。例如哨兵模式、集群（cluster）模式实现高可用。

2、使用“熔断”机制。应用记录当前服务的请求失败率，根据请求失败率来判定拒绝部分或者所有请求，并返回一个预设的结果。

缓存击穿（热点数据集中失效）

通常情况下，都会给缓存设定一个失效时间，过了失效时间后，该数据会被缓存直接删除，从而一定程度上保证数据的实时性。

但是，对于一些请求量极高的热点数据而言，一旦过了有效时间，此刻将会有大量请求落在数据库上，从而可能会导致数据库崩溃。

如果某一个热点数据失效，那么当再次有该数据的查询请求[req-1]时就会前往数据库查询。但是，从请求发往数据库，到该数据更新到缓存中的这段时间中，由于缓存中仍然没有该数据，因此这段时间内到达的查询请求都会落到数据库上，这将会对数据库造成巨大的压力。此外，当这些请求查询完成后，都会重复更新缓存。

解决方案：

1、互斥锁：只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。

当第一个数据库查询请求发起后，就将缓存中该数据上锁；此时到达缓存的其他查询请求将无法查询该字段，从而被阻塞等待；当第一个请求完成数据库查询，并将数据更新值缓存后，释放锁；此时其他被阻塞的查询请求将可以直接从缓存中查到该数据；

当某一个热点数据失效后，只有第一个数据库查询请求发往数据库，其余所有的查询请求均被阻塞，从而保护了数据库。但是，由于采用了互斥锁，其他请求将会阻塞等待，此时系统的吞吐量将会下降。这需要结合实际的业务考虑是否允许这么做；

互斥锁可以避免某一个热点数据失效导致数据库崩溃的问题，而在实际业务中，往往会存在一批热点数据同时失效的场景。对于这种场景一般采用设置不同的失效时间的方法防止数据库过载：在一个基础时间上加/减一个随机数，从而将这些缓存的失效时间错开。

2、永不过期：从缓存层面来看，确实没有设置过期时间，所以不会出现热点 key 过期后产生的问题，也就是“物理”不过期；从功能层面来看，为每个 value 设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。

此方法有效杜绝了热点 key 产生的问题，但唯一不足的就是重构缓存期间，会出现数据不一致的情况，这取决于应用方是否容忍这种不一致。

选择：互斥锁 (mutex key)，思路比较简单，可能会存在死锁和线程池阻塞的风险，但在在一致性上做的比较好；“永远不过期”，会存在数据不一致的情况，同时代码复杂度会增大。根据不同的业务进行选择。

缓存与数据库数据一致性

数据库和缓存更新，就容易出现缓存和数据库间的数据一致性问题。以Redis和Mysql为例：

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

因为写和读是并发的，没法保证顺序，就会出现缓存和数据库的数据不一致的问题。

解决方案：

1、延时双删策略：在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。

• 缓存删除key；
• 数据库更新key对应的data；
• 休眠（一般500ms）；
• 缓存再次删除key；

2、串行化：维护一个队列（内存队列，消息队列）。

写流程：

先删除缓存，删除之后再更新DB，监听从库(资源少的话主库也ok)的binlog，通过分析binlog解析出需要需要刷新的数据标识，然后将数据标识写入队列，接下来就消费队列，解析队列消息来读库获取相应的数据刷新缓存。

读流程：

先读缓存，如果缓存没读到，则去读DB，之后再异步将数据标识写入队列（这里队列与写流程的队列是同一个），接下来就消费队列，解析队列消息来读库获取相应的数据刷新缓存。