Redis 用作缓存
参考：
由于 Redis 提供了高性能的数据存取功能，因此被广泛应用到缓存的场景中，这可以有效提升业务的响应速度，同时避免把压力累积到数据库层面。
掌握缓存需要解决四个关键问题：
- Redis 缓存具体是怎么工作的？(工作原理)
- Redis 缓存如果满了，该怎么办？(替换策略)
- 为什么会有缓存一致性、缓存穿透、缓存雪崩、缓存击穿等异常，该如何应对？(异常处理机制)
- Redis 的内存毕竟有限，如果用快速的固态硬盘来保存数据，可以增加缓存的数据量，那 Redis 缓存可以使用快速固态硬盘吗？(扩展机制)
下面分别介绍。
# 1. 旁路缓存：Redis 是如何工作的？
这一大节主要了解下缓存的特征和Redis适用于缓存的天然优势，以及Redis缓存的具体工作机制。
# 1.1 缓存的特征
计算机系统中，默认有两种缓存：
- CPU里面的末级缓存，即LLC，用来缓存内存中的数据，避免每次从内存中存取数据；
- 内存中的高速页缓存，即page cache，用来缓存磁盘中的数据，避免每次从磁盘中存取数据。
具体如下图所示：
LLC的大小是MB级别，page cache的大小是GB级别，而磁盘的大小是TB级别。
缓存的第一个特征：在一个层次化的系统中，缓存一定是一个快速子系统，数据存在缓存中时，能避免每次从慢速子系统中存取数据。对应到互联网应用来说，Redis 就是快速子系统，而数据库就是慢速子系统了。
缓存的第二个特征：缓存系统的容量大小总是小于后端慢速系统的，我们不可能把所有数据都放在缓存系统中。因此缓存和慢速系统之间必然存在数据写回和再读取的交互过程。这你可能会想到 Redis 本身是支持按一定规则淘汰数据的，相当于实现了缓存的数据淘汰，其实，这也是 Redis 适合用作缓存的一个重要原因。
# 1.2 Redis 缓存处理请求的两种情况
把 Redis 用作缓存时，我们会把 Redis 部署在数据库的前端，业务应用在访问数据时，会先查询 Redis 中是否保存了相应的数据。此时，根据数据是否存在缓存中，会有两种情况：
- 缓存命中
- 缓存缺失：这时需要进行缓存更新，这涉及到数据一致性的问题（会在后文讲述）
由此，使用 Redis 作为缓存主要有三个操作：
- 应用读取数据时，需要先读取 Redis；
- 发生缓存缺失时，需要从数据库读取数据；
- 发生缓存缺失时，还需要更新缓存。
那么，这些操作具体是由谁来做的呢？这和Redis缓存的使用方式相关。接下来就和你聊聊 Redis 作为旁路缓存的使用操作方式。
# 1.3 Redis 作为旁路缓存的使用操作
Redis是一个独立的系统软件，和业务应用程序是两个软件，当我们部署了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做缓存了。
在使用旁路缓存时，我们需要在应用程序中增加操作代码，增加了使用Redis缓存的额外工作量，但是，也正因为Redis是旁路缓存，是一个独立的系统，我们可以单独对Redis缓存进行扩容或性能优化。而且，只要保持操作接口不变，我们在应用程序中增加的代码就不用再修改了。
应用程序除了读取数据外，还可能对数据进行修改。这时我们既可以在缓存中修改，也可以在后端数据库中进行修改，我们该怎么选择呢？
其实，这就涉及到了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 算法在所有数据中进行筛选。
这也就是说，如果一个键值对被删除策略选中了，即使它的过期时间还没到，也需要被删除。当然，如果它的过期时间到了但未被策略选中，同样也会被删除。
LRU和LFU都是内存管理的页面置换算法。
- LRU：最近最少使用(最长时间)淘汰算法（Least Recently Used）。LRU是淘汰最长时间没有被使用的页面。
- LFU：最不经常使用(最少次)淘汰算法（Least Frequently Used）。LFU是淘汰一段时间内，使用次数最少的页面。
关于 LRU 算法：
筛选最不常用数据的方法：把所有的数据组织成一个链表，链表的头和尾分别表示MRU端和LRU端，分别代表最近最常使用的数据和最近最不常用的数据。具体如下图：
但是如上方法由于使用链表管理所有的缓存数据，会带来额外的空间开销，且有大量数据被访问时，需要在链表上移动大量数据，很耗时，降低 Redis 缓存性能。
Redis 中，LRU 算法被做了简化，以减轻数据淘汰对缓存性能的影响。具体来说，Redis默认会记录每个数据的最近一次访问的时间戳（由键值对数据结构RedisObject中的lru字段记录）。然后，Redis在决定淘汰的数据时，第一次会随机选出N个数据，把它们作为一个候选集合。接下来，Redis会比较这N个数据的lru字段，把lru字段值最小的数据从缓存中淘汰出去。
Redis提供了一个配置参数maxmemory-samples，这个参数就是Redis选出的数据个数N。例如，我们执行如下命令，可以让Redis选出100个数据作为候选数据集：
CONFIG SET maxmemory-samples 100
当需要再次淘汰数据时，Redis需要挑选数据进入第一次淘汰时创建的候选集合。这儿的挑选标准是： 能进入候选集合的数据的lru字段值必须小于候选集合中最小的lru值。当有新数据进入候选数据集后，如果候选数据集中的数据个数达到了maxmemory-samples，Redis就把候选数据集中lru字段值最小的数据淘汰出去。
这样一来，Redis缓存不用为所有的数据维护一个大链表，也不用在每次数据访问时都移动链表项，提升了缓存的性能。
关于缓存淘汰策略的选取，有如下建议：
- 优先使用 allkeys-lru 策略。这样可以充分利用 LRU 这一经典缓存算法的优势，把最近最常访问的数据留在缓存中，提升应用的访问性能。如果你的业务数据中有明显的冷热数据区分，我建议你使用 allkeys-lru 策略。
- 如果业务应用中的数据访问频率相差不大，没有明显的冷热数据区分，建议使用allkeys-random策略，随机选择淘汰的数据就行。
- 如果你的业务中有置顶的需求，比如置顶新闻、置顶视频，那么，可以使用 volatile-lru 策略，同时不给这些置顶数据设置过期时间。这样一来，这些需要置顶的数据一直不会被删除，而其他数据会在过期时根据 LRU 规则进行筛选。
一旦被淘汰的数据被选定后，Redis 怎么处理这些数据呢？这就要说到缓存替换时的具体操作了。
# 2.3 如何处理被淘汰的数据？
一般来说，一旦被淘汰的数据选定后，如果这个数据是干净数据，那么我们就直接删除；如果这个数据是脏数据，我们需要把它写回数据库，如下图所示：
- 干净数据：取出来后就没改过
- 脏数据：和后端数据库不一致了
不过，对于Redis来说，它决定了被淘汰的数据后，会把它们删除。即使淘汰的数据是脏数据，Redis 也不会把它们写回数据库。所以，我们在使用 Redis 缓存时，如果数据被修改了，需要在数据修改时就将它写回数据库。否则，这个脏数据被淘汰时，会被 Redis 删除，而数据库里也没有最新的数据了。