Redis 用作缓存
参考：
由于 Redis 提供了高性能的数据存取功能，因此被广泛应用到缓存的场景中，这可以有效提升业务的响应速度，同时避免把压力累积到数据库层面。
掌握缓存需要解决四个关键问题：
- Redis 缓存具体是怎么工作的？
- Redis 缓存如果满了，该怎么办？
- 为什么会有缓存一致性、缓存穿透、缓存雪崩、缓存击穿等异常，该如何应对？
- Redis 的内存毕竟有限，如果用快速的固态硬盘来保存数据，可以增加缓存的数据量，那 Redis 缓存可以使用快速固态硬盘吗？
下面分别介绍。
# 1. 旁路缓存：Redis 是如何工作的？
这一大节主要了解下缓存的特征和Redis适用于缓存的天然优势，以及Redis缓存的具体工作机制。
# 1.1 缓存的特征
缓存的第一个特征：在一个层次化的系统中，缓存一定是一个快速子系统，数据存在缓存中时，能避免每次从慢速子系统中存取数据。对应到互联网应用来说，Redis 就是快速子系统，而数据库就是慢速子系统了。
缓存的第二个特征：缓存系统的容量大小总是小于后端慢速系统的，我们不可能把所有数据都放在缓存系统中。因此缓存和慢速系统之间必然存在数据写回和再读取的交互过程。这你可能会想到 Redis 本身是支持按一定规则淘汰数据的，相当于实现了缓存的数据淘汰，其实，这也是 Redis 适合用作缓存的一个重要原因。
# 1.2 Redis 缓存处理请求的两种情况
把 Redis 用作缓存时，我们会把 Redis 部署在数据库的前端，业务应用在访问数据时，会先查询 Redis 中是否保存了相应的数据。此时，根据数据是否存在缓存中，会有两种情况：
- 缓存命中
- 缓存缺失：这时需要进行缓存更新，这涉及到数据一致性的问题
由此，使用 Redis 作为缓存主要有三个操作：
- 应用读取数据时，需要先读取 Redis；
- 发生缓存缺失时，需要从数据库读取数据；
- 发生缓存缺失时，还需要更新缓存。
那么，这些操作具体是由谁来做的呢？这和Redis缓存的使用方式相关。接下来就和你聊聊 Redis 作为旁路缓存的使用操作方式。
# 1.3 Redis 作为旁路缓存的使用操作
如果应用程序想要使用 Redis 缓存，我们就要在程序中增加相应的缓存操作代码，所以也把 Redis 称为旁路缓存，也就是说，读取缓存、读取数据库和更新缓存的操作都需要在应用程序中来完成。
这种旁路缓存与计算机系统中的缓存不太一样，比如计算机系统中的 page cache 并不需要你去显示调用它的 GET 接口等，而是计算机直接将这些缓存放在了程序的数据访问路径上并直接使用。
在使用 Redis 作为缓存时，我们需要在应用程序中增加三方面的代码：
- 当应用程序需要读取数据时，我们需要在代码中显式调用 Redis 的 GET 操作接口，进行查询；
- 如果缓存缺失了，应用程序需要再和数据库连接，从数据库中读取数据；
- 当缓存中的数据需要更新时，我们也需要在应用程序中显式地调用 SET 操作接口，把更新的数据写入缓存。
下面是一段在 Web 应用中使用 Redis 缓存的伪代码示例：
String cacheKey = “productid_11010003”;
String cacheValue = redisCache.get(cacheKey)；
//缓存命中
if (cacheValue != NULL)
return cacheValue;
//缓存缺失
else
cacheValue = getProductFromDB();
redisCache.put(cacheValue) //缓存更新
2
3
4
5
6
7
8
9
可以看到，为了使用缓存，Web 应用程序需要有一个表示缓存系统的实例对象 redisCache，还需要主动调用 GET 接口，并且要处理缓存命中和缓存缺失时的逻辑，例如在缓存缺失时，需要更新缓存。
应用程序除了读取数据外，还可能对数据进行修改。这时我们既可以在缓存中修改，也可以在后端数据库中进行修改，我们该怎么选择呢？
其实，这就涉及到了Redis缓存的两种类型：
- 只读缓存能加速读请求
- 读写缓存可以同时加速读写请求。
而且，读写缓存又有两种数据写回策略，可以让我们根据业务需求，在保证性能和保证数据可靠性之间进行选择。所以，接下来，我们来具体了解下 Redis 的缓存类型和相应的写回策略。
# 1.4 缓存的类型
按照是否接受写请求，可以分成只读缓存和读写缓存。
# 1.4.1 只读缓存
当Redis用作只读缓存时，应用要读取数据的话，会先调用 Redis GET 接口，查询数据是否存在。而所有的数据写请求，会直接发往后端的数据库，在数据库中增删改。对于删改的数据来说，如果 Redis 已经缓存了相应的数据，应用需要把这些缓存的数据删除，Redis 中就没有这些数据了。
当应用再次读取这些数据时，会发生缓存缺失，应用会把这些数据从数据库中读出来，并写到缓存中。这样一来，这些数据后续再被读取时，就可以直接从缓存中获取了，能起到加速访问的效果。
下图展示了应用修改数据 A 后再次访问 A 的过程：
只读缓存直接在数据库中更新数据的好处是，所有最新的数据都在数据库中，这些数据不会有丢失的风险。当我们需要缓存图片、短视频这些用户只读的数据时，就可以使用只读缓存这个类型了。
# 1.4.2 读写缓存
对于读写缓存来说，除了读请求会发送到缓存进行处理，所有的写请求也会发送到缓存，在缓存中直接对数据进行增删改操作。得益于 Redis 的高性能访问特性，数据的增删改操作可以在缓存中快速完成，处理结果也会快速返回给业务应用，这就可以提升业务应用的响应速度。
但是，和只读缓存不一样的是，在使用读写缓存时，最新的数据是在Redis中，而Redis是内存数据库，一旦出现掉电或宕机，内存中的数据就会丢失。这也就是说，应用的最新数据可能会丢失，给应用业务带来风险。
根据业务应用对数据可靠性和缓存性能的不同要求，有同步直写和异步写回两种策略，如下图所示：
- 同步直写策略优先保证数据可靠性
- 异步写回策略优先提供快速响应
关于是选择只读缓存，还是读写缓存，主要看我们对写请求是否有加速的需求：
- 如果需要对写请求进行加速，我们选择读写缓存；
- 如果写请求很少，或者是只需要提升读请求的响应速度的话，我们选择只读缓存。
举个例子，在商品大促的场景中，商品的库存信息会一直被修改。如果每次修改都需到数据库中处理，就会拖慢整个应用，此时，我们通常会选择读写缓存的模式。而在短视频App的场景中，虽然视频的属性有很多，但是，一般确定后，修改并不频繁，此时，在数据库中进行修改对缓存影响不大，所以只读缓存模式是一个合适的选择。
# 2. 替换策略：缓存满了怎么办？
缓存空间有限，这就涉及到了缓存系统的一个重要机制：缓存替换机制。简单来说，数据淘汰机制包括两步：
- 根据一定的策略，筛选出对应用访问来说“不重要”的数据；
- 将这些数据从缓存中删除，为新来的数据腾出空间
这一节将主要探讨缓存替换策略。
# 2.1 设置多大的缓存容量合适？
缓存容量的设置会直接影响到缓存的性价比。
由于局部性原理，往往一部分数据就支撑了巨大的访问量。如下图：
- 蓝线表示“二八原理”，即20%的数据贡献了80%的访问，而剩余的数据虽然体量很大，但只贡献了20%的访问量。这80%的数据在访问量上就形成了一条长长的尾巴，我们也称为长尾效应。
- 但实际中随着用户的个性化需求越来越多，不同用户访问的内容可能差别很大，导致可能不再具备二八原理分布特征了，也就是说，20%的数据可能贡献不了80%的访问，而剩余的80%数据反而贡献了更多的访问量，我们称之为重尾效应。
因此，缓存的容量规划不能一概而论，是需要结合应用数据实际访问特征和成本开销来综合考虑的，这里也存在 trade-off。
一般，建议把缓存容量设置为总数据量的15%到30%，兼顾访问性能和内存空间开销。
对于 Redis 来说，一旦确定了缓存最大容量，比如 4GB，你就可以使用下面这个命令来设定缓存的大小了：
CONFIG SET maxmemory 4gb
不过，缓存被写满是不可避免的，所以需要缓存替换。缓存替换需要解决两个问题：决定淘汰哪些数据，如何处理那些被淘汰的数据。接下来就讨论 Redis 中的数据淘汰策略。
# 2.2 Redis 缓存有哪些淘汰策略？
Redis 4.0 之后一共有 8 种内存淘汰策略，总结如下图：
默认情况下是 noeviction 策略：Redis 在使用的内存空间超过 maxmemory 值时，并不会淘汰数据，再有写请求的话直接返回错误。因此不把这种方式用到 Redis 缓存中。
我们再分析下 volatile-random、volatile-ttl、volatile-lru 和 volatile-lfu 这四种淘汰策略。它们筛选的候选数据范围，被限制在已经设置了过期时间的键值对上。也正因为此，即使缓存没有写满，这些数据如果过期了，也会被删除。例如，我们使用 EXPIRE 命令对一批键值对设置了过期时间后，无论是这些键值对的过期时间是快到了，还是 Redis 的内存使用量达到了 maxmemory 阈值，Redis 都会进一步按照 volatile-ttl、volatile-random、volatile-lru、volatile-lfu 这四种策略的具体筛选规则进行淘汰：
- volatile-ttl 在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除。
- volatile-random 就像它的名称一样，在设置了过期时间的键值对中，进行随机删除。
- volatile-lru 会使用 LRU 算法筛选设置了过期时间的键值对。
- volatile-lfu 会使用 LFU 算法选择设置了过期时间的键值对。
allkeys-lru、allkeys-random、allkeys-lfu这三种淘汰策略的备选淘汰数据范围，就扩大到了所有键值对，无论这些键值对是否设置了过期时间。它们筛选数据进行淘汰的规则是：
- allkeys-random 策略，从所有键值对中随机选择并删除数据；
- allkeys-lru 策略，使用 LRU 算法在所有数据中进行筛选。
- allkeys-lfu 策略，使用 LFU 算法在所有数据中进行筛选。
这也就是说，如果一个键值对被删除策略选中了，即使它的过期时间还没到，也需要被删除。当然，如果它的过期时间到了但未被策略选中，同样也会被删除。
关于缓存淘汰策略的选取，有如下建议：
- 优先使用 allkeys-lru 策略。这样可以充分利用 LRU 这一经典缓存算法的优势，把最近最常访问的数据留在缓存中，提升应用的访问性能。如果你的业务数据中有明显的冷热数据区分，我建议你使用 allkeys-lru 策略。
- 如果业务应用中的数据访问频率相差不大，没有明显的冷热数据区分，建议使用allkeys-random策略，随机选择淘汰的数据就行。
- 如果你的业务中有置顶的需求，比如置顶新闻、置顶视频，那么，可以使用 volatile-lru 策略，同时不给这些置顶数据设置过期时间。这样一来，这些需要置顶的数据一直不会被删除，而其他数据会在过期时根据 LRU 规则进行筛选。
一旦被淘汰的数据被选定后，Redis 怎么处理这些数据呢？这就要说到缓存替换时的具体操作了。
# 2.3 如何处理被淘汰的数据？
一般来说，一旦被淘汰的数据选定后，如果这个数据是干净数据，那么我们就直接删除；如果这个数据是脏数据，我们需要把它写回数据库，如下图所示：
- 干净数据：取出来后就没改过
- 脏数据：和后端数据库不一致了
不过，对于Redis来说，它决定了被淘汰的数据后，会把它们删除。即使淘汰的数据是脏数据，Redis 也不会把它们写回数据库。所以，我们在使用 Redis 缓存时，如果数据被修改了，需要在数据修改时就将它写回数据库。否则，这个脏数据被淘汰时，会被 Redis 删除，而数据库里也没有最新的数据了。
# 3. 缓存异常（上）：如何解决缓存和数据库的数据不一致问题？
Redis 用作缓存经常有一些异常问题，概括来说有 4 个方面：缓存中的数据和数据库中的不一致；缓存雪崩；缓存击穿和缓存穿透。这一节先看一下第一个问题。
# 3.1 缓存和数据库的数据不一致是如何发生的？
这里的数据的一致性其实包含两种情况：
- 缓存中有数据，且与数据库中的相同
- 缓存中本身没有数据，且数据库中是最新的
不符合这两种情况的，就属于缓存和数据库的数据不一致问题了。当缓存的读写模式不同时，我们的应对方法也不一样。
对于读写缓存来说，数据的 CRUD 要在缓存中进行，同时对原数据库进行写回：
- 若想要保证缓存与数据库的数据一致，就要使用事务机制来使用同步直写策略来一块更新缓存和数据库。
- 若对一致性要求没有那么高，就可以使用异步写回策略。
对于只读缓存来说，如果有数据新增，会直接写入数据库；而有数据删改时，就需要把只读缓存中的数据标记为无效。这样一来，应用后续再访问这些增删改的数据时，因为缓存中没有相应的数据，就会发生缓存缺失。此时，应用再从数据库中把数据读入缓存，这样后续再访问数据时，就能够直接从缓存中读取了。这个过程如下图所示：
从图中可以看到，Tomcat上运行的应用，无论是新增（Insert操作）、修改（Update操作）、还是删除（Delete操作）数据X，都会直接在数据库中增改删。当然，如果应用执行的是修改或删除操作，还会删除缓存的数据X。
那这个过程会不会出现数据不一致的情况呢？考虑到新增数据和删改数据的情况不一样，所以我们分开来看：
# 1）新增数据
如果是新增数据，数据会直接写到数据库中，不用对缓存做任何操作，此时，缓存中本身就没有新增数据，而数据库中是最新值，因此是一致的。
# 2）删改数据
此时就要选择是先更新原数据库的数据还是先删除缓存中的数据：
- 如果先删缓存值：可能导致数据库更新失败
- 如果先更新数据库的值：可能出现后续请求再次缓存命中导致读取缓存旧值
可以看到，无论这两个操作的执行顺序谁先谁后，只要有一个操作失败了，就会导致客户端读取到旧值。如何解决这个问题呢？
# 3.2 如何解决数据不一致问题？
# 3.2.1 重试机制
首先一种方法是：重试机制。
具体来说，可以把要删除的缓存值或者是要更新的数据库值暂存到消息队列中（例如使用Kafka消息队列）。当应用没有能够成功地删除缓存值或者是更新数据库值时，可以从消息队列中重新读取这些值，然后再次进行删除或更新。
如果能够成功地删除或更新，我们就要把这些值从消息队列中去除，以免重复操作，此时，我们也可以保证数据库和缓存的数据一致了。否则的话，我们还需要再次进行重试。如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了。
图显示了先更新数据库，再删除缓存值时，如果缓存删除失败，再次重试后删除成功的情况：
# 3.2.2 延迟双删
刚刚说的是在更新数据库和删除缓存值的过程中，其中一个操作失败的情况，实际上，即使这两个操作第一次执行时都没有失败，当有大量并发请求时，应用还是有可能读到不一致的数据。
同样，我们按照不同的删除和更新顺序，分成两种情况来看。在这两种情况下，我们的解决方法也有所不同。
情况一：先删除缓存，再更新数据库：
假设线程A删除缓存值后，还没有来得及更新数据库（比如说有网络延迟），线程B就开始读取数据了，那么这个时候，线程B会发现缓存缺失，就只能去数据库读取。这会带来两个问题：
- 线程B读取到了旧值；
- 线程B是在缓存缺失的情况下读取的数据库，所以，它还会把旧值写入缓存，这可能会导致其他线程从缓存中读到旧值。
等到线程B从数据库读取完数据、更新了缓存后，线程A才开始更新数据库，此时，缓存中的数据是旧值，而数据库中的是最新值，两者就不一致了。这种情况用表格展示如下：
这该怎么办？一种解决方案是：在线程A更新完数据库值以后，我们可以让它先sleep一小段时间，再进行一次缓存删除操作。
之所以要加上sleep的这段时间，就是为了让线程B能够先从数据库读取数据，再把缺失的数据写入缓存，然后，线程A再进行删除。所以，线程A sleep的时间，就需要大于线程B读取数据再写入缓存的时间。这个时间怎么确定呢？建议你在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，以此为基础来进行估算。
这样一来，其它线程读取数据时，会发现缓存缺失，所以会从数据库中读取最新值。因为这个方案会在第一次删除缓存值后，延迟一段时间再次进行删除，所以我们也把它叫做延迟双删。下面是延迟双删的伪代码：
redis.delKey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)
2
3
4
情况二：先更新数据库值，再删除缓存值：
如果线程A删除了数据库中的值，但还没来得及删除缓存值，线程B就开始读取数据了，那么此时，线程B查询缓存时，发现缓存命中，就会直接从缓存中读取旧值。不过，在这种情况下，如果其他线程并发读缓存的请求不多，那么，就不会有很多请求读取到旧值。而且，线程A一般也会很快删除缓存值，这样一来，其他线程再次读取时，就会发生缓存缺失，进而从数据库中读取最新值。所以，这种情况对业务的影响较小。
这种情况用表格展示为：
到这里我们可以知道，缓存和数据库的数据不一致一般是由两个原因导致的，本节并提供了相应的解决方案：
- 删除缓存值或更新数据库失败而导致数据不一致，你可以使用重试机制确保删除或更新操作成功。
- 在删除缓存值、更新数据库的这两步操作中，有其他线程的并发读操作，导致其他线程读取到旧值，应对方案是延迟双删。
# 3.3 小结
这一大节讲了缓存不一致的问题，可以分成读写缓存和只读缓存两种情况分析。
- 对于读写缓存，同步写回策略就可以保证缓存和数据库中的数据一致。
- 对于只读缓存，可以总结为下面这张表：
大多数业务中，我们是把 Redis 当做只读缓存来使用，并建议优先使用先更新数据库再删除缓存的方法，原因主要有两个：
- 先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力；
- 如果业务应用中读取数据库和写缓存的时间不好估算，那么，延迟双删中的等待时间就不好设置。
# 4. 缓存异常（下）：如何解决缓存雪崩、击穿、穿透难题？
除了缓存不一致，还有三种可能的缓存异常：缓存雪崩、缓存击穿和缓存穿透。这三个问题一旦发生，会导致大量的请求积压到数据库层，从而导致数据库宕机或者故障。
# 4.1 缓存雪崩
缓存雪崩：指大量的应用请求无法在 Redis 缓存中进行处理，紧接着应用将大量请求发送到数据库层，导致数据库层的压力激增。
缓存雪崩一般是由两个原因导致的，应对方案也有所不同，我们一个个来看。
# 4.1.1 原因一：大量数据同时过期
缓存雪崩的第一种原因：缓存中有大量数据同时过期，导致大量请求无法得到处理。
具体来说，当数据保存在缓存中，并且设置了过期时间时，如果在某一个时刻，大量数据同时过期，此时，应用再访问这些数据的话，就会发生缓存缺失。紧接着，应用就会把请求发送给数据库，从数据库中读取数据。如果应用的并发请求量很大，那么数据库的压力也就很大，这会进一步影响到数据库的其他正常业务请求处理。我们来看一个简单的例子，如下图所示：
针对大量数据同时失效带来的缓存雪崩问题，有两种解决方案：
- 微调过期时间：业务避免给大量的数据设置相同的过期时间。如果业务层的确要求有些数据同时失效，你可以在用 EXPIRE 命令给每个数据设置过期时间时，给这些数据的过期时间增加一个较小的随机数。
- 服务降级：指发生缓存雪崩时，针对不同的数据采取不同的处理方式：
- 当业务应用访问的是非核心数据（例如电商商品属性）时，暂时停止从缓存中查询这些数据，而是直接返回预定义信息、空值或是错误信息；
- 当业务应用访问的是核心数据（例如电商商品库存）时，仍然允许查询缓存，如果缓存缺失，也可以继续通过数据库读取。
# 4.1.2 原因二：Redis 缓存实例发生宕机
缓存雪崩的第二种原因：Redis 缓存实例发生故障宕机了，无法处理请求，这就会导致大量请求一下子积压到数据库层，从而发生缓存雪崩。
一般来说，一个 Redis 实例可以支持数万级别的请求处理吞吐量，而单个数据库可能只能支持数千级别的请求处理吞吐量，它们两个的处理能力可能相差了近十倍。由于缓存雪崩，Redis 缓存失效，所以，数据库就可能要承受近十倍的请求压力，从而因为压力过大而崩溃。
这种情况下由于 Redis 实例发生了宕机，我们需要通过其他方法来应对缓存雪崩了。我给你提供两个建议：
第一个建议：在业务系统中实现服务熔断或请求限流机制。
所谓的服务熔断，是指在发生缓存雪崩时，为了防止引发连锁的数据库雪崩，甚至是整个系统的崩溃，我们暂停业务应用对缓存系统的接口访问，而是直接返回，等到Redis缓存实例重新恢复服务后，再允许应用请求发送到缓存系统。这样避免了大量请求因缓存缺失而积压到数据库系统。
在业务系统运行时，我们可以监测 Redis 所在机器和数据库所在机器的负载指标，例如每秒请求数、CPU利用率、内存利用率等。如果我们发现 Redis 实例宕机了，而数据库所在机器的负载压力突然增加，此时就发生缓存雪崩了。大量请求被发送到数据库进行处理。我们可以启动服务熔断机制，暂停业务应用对缓存服务的访问，从而降低对数据库的访问压力，如下图所示：
服务熔断虽然可以保证数据库的正常运行，但是暂停了整个缓存系统的访问，对业务应用的影响范围大。为了尽可能减少这种影响，我们也可以进行请求限流：指我们在业务系统的请求入口前端控制每秒进入系统的请求数，避免过多的请求被发送到数据库。
使用服务熔断或是请求限流机制，来应对Redis实例宕机导致的缓存雪崩问题，是属于“事后诸葛亮”，也就是已经发生缓存雪崩了，我们使用这两个机制，来降低雪崩对数据库和整个业务系统的影响。
第二个建议：事前预防，构建 Redis 集群。
通过主从节点的方式构建 Redis 缓存高可靠集群。如果 Redis 缓存的主节点故障宕机了，从节点还可以切换成为主节点，继续提供缓存服务，避免了由于缓存实例宕机而导致的缓存雪崩问题。
缓存雪崩是发生在大量数据同时失效的场景下，而接下来我要向你介绍的缓存击穿，是发生在某个热点数据失效的场景下。和缓存雪崩相比，缓存击穿失效的数据数量要小很多，应对方法也不一样，我们来看下。
# 4.2 缓存击穿
缓存击穿是指，针对某个访问非常频繁的热点数据的请求，无法在缓存中进行处理，紧接着，访问该数据的大量请求，一下子都发送到了后端数据库，导致了数据库压力激增，会影响数据库处理其他请求。缓存击穿的情况，经常发生在热点数据过期失效时，如下图所示：
为了避免缓存击穿给数据库带来的激增压力，我们的解决方法也比较直接：对于访问特别频繁的热点数据，我们就不设置过期时间了。这样一来，对热点数据的访问请求，都可以在缓存中进行处理，而 Redis 数万级别的高吞吐量可以很好地应对大量的并发请求访问。
# 4.3 缓存穿透
缓存穿透指要访问的数据既不在 Redis 缓存中，也不在数据库中，导致请求在访问缓存时，发生缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据。此时，应用也无法从数据库中读取数据再写入缓存，来服务后续请求，这样一来，缓存也就成了“摆设”，如果应用持续有大量请求访问数据，就会同时给缓存和数据库带来巨大压力，如下图所示：
那么，缓存穿透会发生在什么时候呢？一般来说，有两种情况：
- 业务层误操作：缓存中的数据和数据库中的数据被误删除了，所以缓存和数据库中都没有数据；
- 恶意攻击：专门访问数据库中没有的数据。
为了避免缓存穿透的影响，我来给你提供三种应对方案。
# 1）方案 1：缓存空值或缺省值
一旦发生缓存穿透，我们就可以针对查询的数据，在Redis中缓存一个空值或是和业务层协商确定的缺省值（例如，库存的缺省值可以设为0）。紧接着，应用发送的后续请求再进行查询时，就可以直接从Redis中读取空值或缺省值，返回给业务应用了，避免了把大量请求发送给数据库处理，保持了数据库的正常运行。
# 2）方案 2：使用布隆过滤器快速判断数据是否存在，避免从数据库中查询数据是否存在，减轻数据库压力
布隆过滤器由一个初值都为0的bit数组和N个哈希函数组成，可以用来快速判断某个数据是否存在。当我们想标记某个数据存在时（例如，数据已被写入数据库），布隆过滤器会通过三个操作完成标记：
- 首先，使用N个哈希函数，分别计算这个数据的哈希值，得到N个哈希值。
- 然后，我们把这N个哈希值对bit数组的长度取模，得到每个哈希值在数组中的对应位置。
- 最后，我们把对应位置的bit位设置为1，这就完成了在布隆过滤器中标记数据的操作。
如果数据不存在（例如，数据库里没有写入数据），我们也就没有用布隆过滤器标记过数据，那么，bit数组对应bit位的值仍然为0。
当需要查询某个数据时，我们就执行刚刚说的计算过程，先得到这个数据在bit数组中对应的N个位置。紧接着，我们查看bit数组中这N个位置上的bit值。只要这N个bit值有一个不为1，这就表明布隆过滤器没有对该数据做过标记，所以，查询的数据一定没有在数据库中保存。这个过程如下图：
图中布隆过滤器是一个包含10个bit位的数组，使用了3个哈希函数，当在布隆过滤器中标记数据X时，X会被计算3次哈希值，并对10取模，取模结果分别是1、3、7。所以，bit数组的第1、3、7位被设置为1。当应用想要查询X时，只要查看数组的第1、3、7位是否为1，只要有一个为0，那么，X就肯定不在数据库中。
正是基于布隆过滤器的快速检测特性，我们可以在把数据写入数据库时，使用布隆过滤器做个标记。当缓存缺失后，应用查询数据库时，可以通过查询布隆过滤器快速判断数据是否存在。如果不存在，就不用再去数据库中查询了。这样一来，即使发生缓存穿透了，大量请求只会查询Redis和布隆过滤器，而不会积压到数据库，也就不会影响数据库的正常运行。布隆过滤器可以使用Redis实现，本身就能承担较大的并发访问压力。
# 3）方案 3：提前对请求进行合法性检测
这种方案是在请求入口的前端进行请求检测。缓存穿透的一个原因是有大量的恶意请求访问不存在的数据，所以，一个有效的应对方案是在请求入口前端，对业务系统接收到的请求进行合法性检测，把恶意的请求（例如请求参数不合理、请求参数是非法值、请求字段不存在）直接过滤掉，不让它们访问后端缓存和数据库。这样一来，也就不会出现缓存穿透问题了。
跟缓存雪崩、缓存击穿这两类问题相比，缓存穿透的影响更大一些，希望你能重点关注一下：
- 从预防的角度来说，我们需要避免误删除数据库和缓存中的数据；
- 从应对角度来说，我们可以在业务系统中使用缓存空值或缺省值、使用布隆过滤器，以及进行恶意请求检测等方法。
# 4.4 小结
本节所讲的三个问题如下图所示：
最后强调一下，服务熔断、服务降级、请求限流这些方法都是属于“有损”方案，在保证数据库和整体系统稳定的同时，会对业务应用带来负面影响。例如使用服务降级时，有部分数据的请求就只能得到错误返回信息，无法正常处理。如果使用了服务熔断，那么，整个缓存系统的服务都被暂停了，影响的业务范围更大。而使用了请求限流机制后，整个业务系统的吞吐率会降低，能并发处理的用户请求会减少，会影响到用户体验。
所以建议尽量使用预防式方案：
- 针对缓存雪崩，合理地设置数据过期时间，以及搭建高可靠缓存集群；
- 针对缓存击穿，在缓存访问非常频繁的热点数据时，不要设置过期时间；
- 针对缓存穿透，提前在入口前端实现恶意请求检测，或者规范数据库的数据删除操作，避免误删除。
# 5. 缓存被污染了，该怎么办？
缓存污染：指有些数据很少被访问，这些数据被访问后仍然继续留在缓存中，就只会白白占用缓存空间，这种情况就是缓存污染。
如果缓存污染严重，就会影响 Redis 的性能。这一节就看看如何解决缓存污染问题。
# 5.1 如何解决缓存污染问题
要解决缓存污染，我们也能很容易想到解决方案，那就是得把不会再被访问的数据筛选出来并淘汰掉。这样就不用等到缓存被写满以后，再逐一淘汰旧数据之后，才能写入新数据了。而哪些数据能留存在缓存中，是由缓存的淘汰策略决定的。
我们前面说过缓存淘汰策略有 8 种，哪些策略可以解决缓存污染问题呢？我们一一分析下。
首先先看一下 volatile-random 和 allkeys-random 这两个策略，它们都是采用随机挑选被淘汰的数据。因为这两个策略并不根据数据的访问情况来筛选，因此在避免缓存污染这个问题上的效果非常有限。
再看 volatile-ttl 策略，它把数据中剩余存活时间最短的筛选出来并淘汰掉，但剩余存活时间也不能直接反映数据再次访问的情况，因此也无法有效避免缓存污染。除非应用会根据访问情况来设置过期时间。
下面再看一下 LRU 和 LFU 策略在解决缓存污染问题上的效果。
# 5.2 LRU 缓存策略
LRU 策略的核心思想：如果一个数据刚刚被访问，那么这个数据肯定是热数据，还会被再次访问。
Redis 的 LRU 缓存策略实现方式是在 RedisObject 结构体上设置了一个 lru 字段来记录时间戳，在进行数据淘汰时，LRU 策略会淘汰掉 lru 值最小的数据。
因此在数据被频繁访问的业务场景中，LRU 策略能够有效留存访问时间最近的数据，而且因为这些数据很可能被再次访问，从而可以提升业务应用的访问速度。
但 LRU 这种只看数据访问时间的算法，无法处理“扫描式单次查询操作”导致的缓存污染问题。扫描式单次查询操作指应用对大量数据进行一次全体逐一访问，此时由于被查询的数据都是刚被访问过的，其 lru 值都很大，从而导致很多数据都留在了缓存中产生污染。
所以对于 Redis 的 LRU 策略 而言，扫描式单次查询会造成缓存污染。为了应对这类问题，Redis 4.0 增加了 LFU 淘汰策略，它从时效性和被访问次数两个维度来筛选数据。下面看一下 LFU 策略。
# 5.3 LFU 缓存策略的优化
LFU 缓存策略是在 LRU 策略基础上，为每个数据增加了一个计数器，来统计这个数据的访问次数。当使用 LFU 策略筛选淘汰数据时，首先会根据数据的访问次数进行筛选，把访问次数最低的数据淘汰出缓存。如果两个数据的访问次数相同，LFU 策略再比较这两个数据的访问时效性，把距离上一次访问时间更久的数据淘汰出缓存。
和那些被频繁访问的数据相比，扫描式单次查询的数据因为不会被再次访问，所以它们的访问次数不会再增加。因此，LFU 策略会优先把这些访问次数低的数据淘汰出缓存。这样一来，LFU 策略就可以避免这些数据对缓存造成污染了。
# 5.4 小结
在实际业务应用中，LRU 和LFU 两个策略都有应用。LRU 和 LFU 两个策略关注的数据访问特征各有侧重：
- LRU 策略更加关注数据的时效性；
- LFU 策略更加关注数据的访问频次。
通常情况下，实际应用的负载具有较好的时间局部性，所以 LRU 策略的应用会更加广泛。但是，在扫描式查询的应用场景中，LFU 策略就可以很好地应对缓存污染问题了，建议你优先使用。