分布式多级缓存系统设计与实战

1. 缓存系统概述

如上图，是一次最基本的网络请求。用户请求从界面（浏览器或 App 界面）到网络转发、应用服务再到存储（数据库或文件系统），然后返回到界面呈现内容。

随着互联网的普及，内容信息越来越复杂，用户数和访问量越来越大，我们的应用需要支撑更多的并发量，同时我们的应用服务器和数据库服务器所做的计算也越来越多。但是往往我们的应用服务器资源是有限的，数据库每秒能接受的请求次数也是有限的。如何能够有效利用有限的资源来提供尽可能大的吞吐量？是每个开发同学绕不开的课题。一个有效的办法就是引入缓存，打破标准流程，如下图1到4每个环节中请求可以从缓存中直接获取目标数据并返回，从而减少计算量，有效提升响应速度，让有限的资源服务更多的用户。

image.png

缓存可以应用上图1到4个的各个环节中，且不同环节缓存策略略有不同。本文将主要从3和4点讲解缓存的使用。

2. 缓存架构演变

2.1. 无缓存架构

如上图，是一次最基本的网络请求。请求从网络层直接请求到 DB。此时请求耗时最大卡点在数据库的磁盘 IO 上。

2.2. 引入分布式缓存数据库

针对2.1无缓存架构的数据库磁盘IO耗时，可添加了一道缓存数据库例如 redis。借助缓存中间件，可消除数据库的 IO 瓶颈。快速返回数据。如下图：

通过缓存数据库1、可防止流量直接打到数据库层，减缓数据库压力。2、缓存快速返回，可提高请求查询速率。

2.2.1 为什么选择redis？

• 纯内存操作，无磁盘 IO 耗时
• key-value 数据库，时间复杂度 O(1),相比数据库的 O(Log n)，访问速度更快
• IO 多路复用线程模型，IO 阶段无阻塞

此时系统卡点在缓存数据库的网络通信上。即使缓存数据库读取数据很快，但是和应用服务间仍然隔着一层网络通信。

2.3. 引入 JVM 本地缓存

针对2.2缓存数据库架构，访问缓存数据库的网络通信问题，可在 JVM 应用层添加本地缓存，解决网络 IO 问题。如下图

在应用内部新增本地缓存，使流量在应用层直接返回。避免进一步访问到 redis。

本架构虽然可大大提高数据读取速率，但其成本也是更高的。

• 需要在多台 JVM 机器上冗余缓存，对内存要求高。
• 缓存在多台 JVM 实例，数据一致性维护成本高。

建议根据自身业务场景，从以下3方面考量是否才有本地缓存。

• 业务访问量 QPS
• 硬件资源内存是否充足
• 变更场景是否频繁

常用本地缓存

• JDK MAP
• guavaCache
• Caffeine Cache

2.3.1 数据读取流程

按优先级依次从本地、redis、DB 中读取数据。实现了本地（一级缓存）、缓存数据库（二级缓存）和 DB 的多级缓存架构。

3. 痛点和优化

3.1 数据一致性问题

存在多级缓存，虽然大大提高了数据的读取速率。但是数据散落在各个不同的区域，数据一致性就是一个绕不过去的问题。特别是针对本地缓存，同时散落在多个多台 JVM 实例中。数据变更时，必须同步修改redis、本地缓存和DB。以下是基于canal + 广播消息实现的一致性异步处理方案。

• DB 修改数据
• 通过监听 canal 消息，触发缓存的更新
• 针对 redis 缓存中，因为集群中只共享一份，直接同步缓存即可
• 针对本地缓存，因为集群中存在多分，且分散在不同的 JVM 实例中。故再借助广播 MQ 机制，通知到各个业务实例。同步本地缓存

3.1.1 同步缓存机制

• 直接删除缓存，查询时直接加载

优点：操作简单

缺点：未命中缓存时，取重新加载。此次查询请求慢。

• 重新加载缓存

• 优点：提前设置缓存，查询效率高

**注意:**此方案同步缓存，为先 DB 操作、后异步同步缓存。会存在短暂 DB 和缓存不一致场景。需根据自身业务场景考量，如有必要，可前置删除缓存，再 DB 操作。

3.2. 热点 key 监控

以上架构，系统缓存只能被动加载。只有 key 被访问后，系统才能触发加载。在高并发的情况下，如一直出现缓存穿透，大量流量请求到数据库，对数据库还是很大的考验。所以优秀的缓存系统，应该能自动识别出热点 key。前置将数据缓存下来。

3.2.1 热点 key 探测

引入缓存中间调度服务：热点 key 探测中间服务器概念

• 1、业务实例汇总 key 访问情况并将上报到“热点 key 探测中间服务器”。
• 2、“热点 key 探测中间服务器”根据各业务实例上报的信息，识别该 key 是否为热点。
• 3、“热点 key 探测中间服务器”将识别结果通知到各业务实例。

• 如若为热点 key：业务实例自动预热缓存，等待流量访问。
• 如若非热点 key：业务实例释放该热点 key，释放内存占用。

详情见：参考

4. 缓存注意事项

4.1 key 设计

• 长度短：redis key 越短，占用内存越小
• 高命中率：命中率不高，缓存意义不大

4.1.1 value 设计

• 尽可能小，避免出现 big key

redis 是单线程机制，big key 会阻塞后续请求。

仅缓存必要的字段，不必要字段，及时瘦身

• 2、改少读多

• 变更频繁的数据不建议缓存，频繁的数据变更会导致缓存实现和一致性同步问题，反而会损耗系统性能

• 3、计算逻辑复杂的结果

4.1.2 缓存穿透

访问一个不存在的 key。由于实际上并不存在，所以每次都会访 DB

• 解决方案

• 缓存空值或默认对象（依据业务场景）
• 布隆过滤器

4.1.3 缓存击穿

某个 key 瞬间访问量过大，但突然过期，导致大部分流量打到了 DB

• 解决方案

• histrix 保护，对 DB 的访问限流
• 只有获得锁的线程才能去 DB 读取数据，并填充到缓存中
• 1.使用互斥锁
• 2.永不过期
• 3.资源保护

4.1.4 缓存雪崩

由于大部分 key 设置了相同的失效时间，某一时间大量缓存同时失效，导致大部分流量瞬间打到 DB，导致 DB 压力过大。

• 解决方法

• key 使用不同的过期时间，或者加一个随机时间

5. 实战经验

• 评估预计占用的缓存大小，避免占满 redis 集群和 JVM 内存
• 评估预计 QPS，如2.2架构。大量从 redis 中获取对象，会涉及平凡的对象反序列化操作，此处存在耗 CPU 操作。
• 严格禁止 bigKey。redis的单线程模型，出现 bigKey 会严重降低 redis 服务吞吐量。
• 必须设置过期时间

6. 踩坑记录

6.1. 本地缓存被污染

由于缓存在 JVM 内部，且保存在老年代。业务方拿去使用的时候，直接修改了缓存的数据，导致缓存数据不正确。

• 解决

取对象时，直接 copy 一份。（复制对象耗 CPU，不推荐）

将缓存对象设置成不可编辑。（推荐）

6.2. 缓存计算结果，而不是响应结果

缓存的 value 是 Response 对象，首次请求失败，导致缓存的数据为response.success=false。后续所有命中均操作失败。

• 解决

• 将缓存结果由 Response，调整为实际的计算结果

6.3. 本地内存彪高，触发频繁 full GC

初次引入本地缓存（之前是 redis ）。将大量数据缓存在本地，导致 JVM 内存彪高。

• 解决

引入本地缓存前考虑预计内存，进而考虑是否值得接入本地缓存。

仅缓存热点 key，非热点 key 不缓存在本地

6.4. 降级到 redis 缓存，CPU 彪高

为优化 JVM 内存，将本地缓存降级到 redis。QPS 高场景，触发大量序列化和young GC，导致系统 CPU 彪高。

• 解决

评估 QPS，考虑是否可降级

仅缓存热点 key，非热点 key 不缓存在本地

7. 总结

在计算机世界里，缓存无处不在。但不管缓存系统如何设计，其本质都是空间换时间。也就是提升数据的获取速率。

缓存系统的设计各有千秋、各有优劣。没有最优秀的架构，只有最适合的架构。应该根据自身实际业务情况考虑缓存架构的设计。并从缓存命中率、数据库压力、数据一致性、系统吞吐量等综合评估设计的合理性。