缓存设计

缓存能够有效地加速应用的读写速度，同时也可以i降低后端负载，对日常应用的开发至关重要。

缓存的收益和成本

下图左侧为客户端直接调用存储层的架构，右侧为比较典型的缓存层 + 存储层架构，下面分析一下缓存加入后带来的收益和成本

缓存层存储层基本流程

收益如下:

加速读写: 因为缓存通常都是内存的(例如 Redis、Memcache)，而存储层通常读写性能不够强悍(例如 MySQL)，通过缓存的使用可以有效地加速读写，优化用户体验

降低后端负载: 帮助后端减少访问量和复杂计算(例如很复杂的 SQL 语句)，在很大程序降低了后端的负载。

成本如下:

数据不一致: 缓存层和存储层的数据存在着一定时间窗口的不一致性，时间窗口跟更新策略有关

代码维护成本: 加入缓存后，需要同时处理缓存层和存储层的逻辑，增大了开发者维护代码的成本。

运维成本: 以 Redis Cluster 为例，加入后无形中增加了运维成本。

缓存的使用场景基本包含如下两种:

开销大的复杂计算: 以 MySQL 为例，一些复杂的操作或者计算(例如大量联表操作、一些分组计算)，如果不加缓存，不但无法满足高并发量，同时也会给 MySQL 带来巨大的负担。

加速请求响应:

即使查询单条后端数据足够快(例如select * from table where id =)，那么依然可以使用缓存，以 Redis 为例子，每秒可以完成数万次读写，并且提供的批量操作可以优化整个 IO 链的响应时间

缓存更新策略

缓存中的数据通常是有生命周期的，需要在指定时间后被删除或更新，这样可以保证缓存空间在一个可控的范围。
但是缓存中的数据会和数据源中的真实数据有一段时间窗口不一致，需要利用某些策略进行更新。
下面分别从使用场景、一致性、开发人员/维护成本三个方面介绍三种缓存的更新策略

LRU/LRU/FIFO 算法剔除

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

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

维护成本:
算法不需要开发人员自己来实现，通常只需要配置最大 maxmemory 和对应的策略即可。
开发人员只需要知道每种算法的含义，选择适合自己的算法即可。

超时剔除

使用场景:
超时剔除通过给缓存数据设置过期时间，让其在过期时间后自动剔除，例如 Redis 提供的 expire 命令。
如果业务可以容忍一段时间内，缓存层数据和存储层数据不一致，那么可以为其设置过期时间。
在数据过期后，再从真实数据源获取数据，重新放到缓存并设置过期时间。
例如一个视频的描述信息，可以容忍几分钟内数据不一致，但是涉及交易方面的业务，后果可想而知。

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

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

主动更新

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

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

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

最佳实践

两个建议:

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

缓存粒度控制

假如现在需要将 MySQL 的用户信息使用 Redis 缓存，可以执行如下操作:

从 MySQL 获取用户信息:

1	`SELECT * FROM user WHERE id = {id};`

将信息缓存到 Redis 中:

1	`set user:{id} 'SELECT * FROM user WHERE id={id}'`

假设用户表有 100 个列，需要缓存到什么维度呢？

缓存全部列:

1	`set user:{id} 'SELECT * FROM user WHERE id={id}'`

缓存部分重要列:

1	`set user:{id} 'SELECT {importantColumn1},{importantColumn2}...{importantColumnN} FROM user where id={id}'`

上述这个问题就是缓存粒度问题，究竟是缓存全部属性还是只缓存部分重要属性呢？
下面将从通用性、空间占用、代码维护三个角度进行说明

通用性:
缓存全部数据比部分数据更加通用，但从实际经验看，很长时间内应用只需要几个重要的属性。

空间占用:
缓存全部数据要比部分数据占用更多的空间，可能存在以下问题:

全部数据会造成内存的浪费
全部数据可能每次传输产生的网络流量会比较大，耗时相对较大，在极端情况下会阻塞网络。
全部数据的序列化和反序列化的 CPU 开销更大

代码维护:
全部数据的优势更加明显，而布恩数据一旦要加新字段需要修改业务代码，而且修改后通常还需要刷新缓存数据。

缓存粒度问题是一个容易被忽视的问题，如果使用不当，可能会造成很多无用空间的浪费，
网络带宽的浪费，代码通用性较差等情况，需要综合数据通用性、空间占用比、代码维护性三点进行取舍。

穿透优化

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

1) 缓存层不命中
2) 存储层不命中，不将空结果写回缓存
3）返回空结果

缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。

缓存穿透问题可能会使后端存储负载加大，由于很多后端存储不具备高并发性，甚至可能造成后端存储宕掉。
通常可以在程序中分别统计总调用数、缓存命中数、存储层命中数，如果发现大量存储层空命中，可能就是出现了缓存穿透问题。

造成缓存穿透的基本原因有两个。
第一，自身业务代码或者数据出现问题，
第二，一些恶意攻击、爬虫等造成大量空命中。

下面来看一下如何解决缓存穿透问题

缓存空对象

当第 2 步存储层不命中后，仍然将空对象保存到缓存层中，之后再访问这个数据将会从缓存中获取，这样就保护了后端数据源。

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

下面给出了缓存空对象的实现代码:

String get(String key) {
    // 从缓存中那个获取数据
    String cacheValue = cache.get(key);
    // 缓存为空
    if (StringUtils.isBlank(cacheValue)) {
        // 从存储中获取
        String storageValue = storage.get(key);
        cache.set(key, storageValue);
        // 如果存储数据为空，需要设置一个过期时间(300秒)
        if (storageValue == null) {
            cache.expire(key, 60 * 5);
        }
        return storageValue;
    } else {
        // 缓存非空
        return cacheValue;
    }
}

布隆过滤器拦截

在访问缓存层和存储层之前，将存在的 key 用布隆过滤器提前保存起来，做第一层拦截。
例如: 一个推荐系统有 4 亿个用户 id，每个小时算法工程师会根据每个用户之前历史行为计算出推荐数据放到存储层中，但是最新的用户由于没有历史行为，就会发生缓存穿透的行为，为此可以将所有推荐数据的用户做成布隆过滤器。
如果布隆过滤器认为该用户 id 不存在，那么就不会访问存储层，在一定程度保护了存储层。

开发提示

可以利用 Redis 的 Bitmaps 实现布隆过滤器
Github 上已经开源了类似的方案，可以进行参考

无底洞优化

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

雪崩优化

什么是缓存雪崩: 由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓存层由于某些原因不能提供服务，于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情况。
缓存雪崩的英文愿意时候 stampeding herd(奔逃的野牛)，指的是缓存层宕掉后，流量会像奔逃的野牛一样，打向后端存储。

预防和解决缓存雪崩问题，可以从以下三个方面进行着手。

(1) 保证缓存层服务高可用性。
和飞机都有多个引擎一样，如果缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如前面介绍过的 Redis Sentinel 和 Redis Cluster 都实现了高可用

(2) 依赖隔离组件为后端限流并降级。无论是缓存层还是存储层都会有出错的概率，可以将它们视同为资源。
作为并发量较大的系统，假如有一个资源不可用，可能会造成线程全部阻塞(hang)在这个资源上，造成整个系统不可用。
降级机制在高并发系统中是非常普遍的: 比如推荐服务中，如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成前端页面是开天窗。
在实际项目中，我们需要对重要的资源(例如 Redis、MySQL、HBase、外部接口)都进行隔离，让每种资源都单独运行在自己的线程池中，即使个别资源出现了问题，对其他服务没有影响。
但是线程池如何管理，比如如何关闭资源池、开启资源池、资源池阈值管理，这些做起来还是相当复杂的。
这里推荐一个 Java 依赖隔离工具 Hystrix(https://github.com/netflix/hystrix)。

(3) 提前演练。在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定。

热点 key 重建优化

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

当前 key 是一个热点 key(例如一个热门的娱乐新闻)，并发量非常大
重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的 SQL、多次 IO、多个依赖等。

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

要解决这个问题也不是很复杂，但是不能为了解决这个问题给系统带来更多的麻烦，所以需要制定如下目标:

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