深入学习Redis之缓存设计与优化

缓存的使用与设计

缓存的收益与成本

收益：

加速读写：CPU L1/L2/L3 Cache、浏览器缓存等。因为缓存通常都是全内存的（例如 Redis、Memcache），而存储层通常读写性能不够强悍（例如 MySQL），通过缓存的使用可以有效地加速读写，优化用户体验。
降低后端负载：帮助后端减少访问量和复杂计算，在很大程度降低了后端的负载。

成本：

数据不一致：缓存层和数据层有时间窗口不一致，和更新策略有关。
代码维护成本：加入缓存后，需要同时处理缓存层和存储层的逻辑，增大了开发者维护代码的成本。
运维成本：以 Redis Cluster 为例，加入后无形中增加了运维成本。

使用场景：

降低后端负载：对高消耗的 SQL：join 结果集/分组统计结果缓存。
加速请求响应：利用 Redis/Memcache 优化 IO 响应时间。
大量写合并为批量写：比如计数器先 Redis 累加再批量写入 DB。

缓存更新策略

缓存中的数据通常都是有生命周期的，需要在指定时间后被删除或更新，这样可以保证缓存空间在一个可控的范围。

但是缓存中的数据会和数据源中的真实数据有一段时间窗口的不一致，需要利用某些策略进行更新。

下面将分别从使用场景、一致性、开发人员开发/维护成本三个方面介绍三种缓存的更新策略。

LRU/LFU/FIFO 算法剔除

LRU：Least Recently Used，最近最少使用。

LFU：Least Frequently Used，最不经常使用。

FIFO：First In First Out，先进先出。

使用场景：剔除算法通常用于缓存使用量超过了预设的最大值时候，如何对现有的数据进行剔除。例如 Redis 使用maxmemory-policy这个配置作为内存最大值后对于数据的剔除策略。

一致性：要清理哪些数据是由具体算法决定，开发人员只能决定使用哪种算法，所以数据的一致性是最差的。

维护成本：算法不需要开发人员自己来实现，通常只需要配置最大maxmemory和对应的策略即可。

超时剔除

使用场景：超时剔除通过给缓存数据设置过期时间，让其在过期时间后自动删除，例如 Redis 提供的 expire 命令。如果业务可以容忍一段时间内，缓存层数据和存储层数据不一致，那么可以为其设置过期时间。在数据过期后，再从真实数据源获取数据，重新放到缓存并设置过期时间。

一致性：一段时间窗口内（取决于过期时间长短）存在一致性问题，即缓存数据和真实数据源的数据不一致。

维护成本：维护成本不是很高，只需设置 expire 过期时间即可，当然前提是应用方允许这段时间可能发生的数据不一致。

主动更新

使用场景：应用方对于数据的一致性要求高，需要在真实数据更新后，立即更新缓存数据。例如可以利用消息系统或者其他方式通知缓存更新。

一致性：一致性最高，但如果主动更新发生了问题，那么这条数据很可能很长时间不会更新，所以建议结合超时剔除一起使用效果会更好。

维护成本：维护成本会比较高，开发者需要自己来完成更新，并保证更新操作的正确性。

总结

策略	一致性	维护成本
LRU/LFU/FIFO	最差	低
超时剔除	较差	低
主动更新	最好	高

建议：

低一致性业务建议配置最大内存和淘汰策略的方式使用。
高一致性业务可以结合使用超时剔除和主动更新，这样即使主动更新出了问题，也能保证数据过期时间后删除脏数据。

缓存粒度控制

一般常用的架构就是缓存层使用 Redis，存储层使用 MySQL。

比如：我们现在需要缓存用户信息。

第一步：从 MySQL 查询，得到结果。

第二步：放入缓存中。

但是，我们是缓存 MySQL 查出的所有列呢，还是某一些比较重要常用的列。

上述这个问题就是缓存粒度问题。

下面将从通用性、空间占用、代码维护三个角度进行说明：

通用性：缓存全部数据比部分数据更加通用，但从实际经验看，很长时间内应用只需要几个重要的属性。
空间占用：缓存全部数据要比部分数据占用更多的空间，可能存在以下问题：
- 全部数据会造成内存的浪费。
- 全部数据可能每次传输产生的网络流量会比较大，耗时相对较大，在极端情况下会阻塞网络。
- 全部数据的序列化和反序列化的 CPU 开销更大。
代码维护：全部数据的优势更加明显，而部分数据一旦要加新字段需要修改业务代码，而且修改后通常还需要刷新缓存数据。

缓存穿透问题

缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，通常出于容错的考虑，如果从存储层查不到数据则不写入缓存层。分为以下三步：

缓存层不命中。
存储层不命中，不将空结果写回缓存。
返回空结果。

缓存穿透带来的问题：

缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。
缓存穿透问题可能会使后端存储负载加大，由于很多后端存储不具备高并发性，甚至可能造成后端存储宕掉。通常可以在程序中分别统计总调用数、缓存层命中数、存储层命中数，如果发现大量存储层空命中，可能就是出现了缓存穿透问题。

造成缓存穿透的原因：

业务代码自身问题。
一些恶意攻击、爬虫等。

穿透优化的方案：

缓存空对象。
布隆过滤器。

缓存空对象

其实也就是当第 2 步存储层没有命中后，仍然将空对象保留到缓存层中，之后再访问这个数据将会从缓存中获取。

这样会带来两种问题：

空值做了缓存存储。意味着缓存中需要更多的内存空间。所以我们还需要针对这种空值增加一个过期时间，例如 1 分钟，3 分钟等等。具体还是根据业务来判断。
这样做后会造成短期内缓存层与存储层有一段时间数据不一致问题，可能会对业务有所影响，比如我们查询商品 ID 为 888，此时缓存层和存储层都没有此 ID 数据，我们进行空值缓存后，如果此时恰好添加了 ID 为 888 的数据，就会导致短期内不一致问题。此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

布隆过滤器

布隆过滤器是在访问缓存层和存储层之前，将存在的 key 用布隆过滤器提前保存起来，做第一层拦截。

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

缓存雪崩问题

由于 Cache 服务承载大量的请求，当 Cache 服务宕机后，大量的流量会直接压向后端组件 DB，造成级联故障。

优化方案

保证缓存高可用性，就算个别节点挂掉，依然还有别的可以提供服务。
依赖隔离组件为后端限流降级，比如使用 Hystrix。
提前演练。

无底洞问题

2010 年，Facebook 的 Memcache 节点已经达到了 3000 个，承载着 TB 级别的缓存数据。但开发和运维人员发现了一个问题，为了满足业务要求添加了大量新 Memcache 节点，但是发现性能不但没有好转反而下降了，当时将这种现象称为缓存的“无底洞”现象。

那么为什么会产生这种现象呢，通常来说添加节点使得 Memcache 集群性能应该更强了，但事实并非如此。键值数据库由于通常采用哈希函数将 key 映射到各个节点上，造成 key 的分布与业务无关，但是由于数据量和访问量的持续增长，造成需要添加大量节点做水平扩容，导致键值分布到更多的节点上，所以无论是 Memcache 还是 Redis 的分布式，批量操作通常需要从不同节点上获取，相比于单机批量操作只涉及一次网络操作，分布式批量操作会涉及多次网络时间。

优化思路

命令本身的优化，例如：keys、hgetall、bigkey 等。
减少网络通信次数。
降低接入成本，例如客户端使用长连接/连接池、NIO 等。

我们下面重点如何降低网络通信次数。

串行 mget

由于 n 个 key 是比较均匀地分布在 Redis Cluster 的各个节点上，因此无法使用 mget 命令一次性获取，所以通常来讲要获取 n 个 key 的值，最简单的方法就是逐次执行 n 个 get 命令，这种操作时间复杂度较高，它的操作时间=n 次网络时间+n 次命令时间。n 是 key 的数量，是最简单的实现方式但显然不是最优的。

串行 IO

Redis Cluster 使用 CRC16 算法计算出散列值，再取对 16383 的余数就可以算出 slot 值，有了这两个数据就可以将属于同一个节点的 key 进行归档，得到每个节点的 key 子列表，之后对每个节点执行 mget 或者 Pipeline 操作。

它的操作时间=node 次网络时间+n 次命令时间。

这种方案比第一种要好一点，但是如果节点数太多，还是有一定的性能问题。

并行 IO

此方案是将方案 2 中的最后一步改为多线程执行，网络次数虽然还是节点个数，但由于使用多线程网络时间变为 O(1)，这种方案会增加编程的复杂度。操作时间为max_slow(node 网络时间)+n 次命令时间。

HASH_TAG

Redis Cluster 的 hash_tag 功能可以强制将多个 key 强制分配到一个节点上，它的操作时间=1 次网络时间+n 次命令时间。

四种思路总结

方案	优点	缺点	时间复杂度
串行命令	简单，如果 key 少的话，性能可以接受	大量 key 的话延迟严重	O(keys)
串行 IO	简单，少量节点，性能满足要求	大量节点的话延迟严重	O(nodes)
并行 IO	并行特性，延迟取决于最慢的节点	编程复杂，多线程定位复杂	O(max_slow(nodes))
hash_tag	性能高	读写增加 tag 维护成本，tag 分布易发生数据倾斜	O(1)

热点 key 的重建优化

我们通常使用的“缓存+过期时间”的策略既可以加速数据读写，又保证数据的定期更新，这种模式基本能够满足绝大部分需求。但是有两个问题如果同时出现，可能就会对应用造成致命的危害：

当前 key 是一个热点 key（例如一个热门的娱乐新闻），并发量非常大。
重建缓存不能在短时间完成，可能是一个复杂计算。

在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。

我们需要制定如下目标：

减少重建缓存的次数。
数据尽可能一致。
减少潜在危险。

下面我们讲解一下两种解决方案。

互斥锁

此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完后，再重新从缓存获取数据即可。

我们可以使用 Redis 的setnx命令来实现互斥锁。

如果 Redis 数据存在则返回，不存在就进入第二步。
如果 setnx 结果为 true，说明没有其它线程重建，我们执行重建缓存逻辑。
如果 setnx 结果为 false，说明有其它的线程正在重建缓存，当前线程可以睡眠指定时间后再去获取缓存数据。

永远不过期

缓存层面：没有设置过期时间。

功能层面：为每个 value 设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。

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

两种方案对比

方案	优点	缺点
互斥锁	思路简单，保证一致性	代码复杂度增加，存在死锁风险
永远不过期	基本杜绝热点 key 重建问题	不保证一致性，逻辑过期时间增加维护成本