现在行动
11 缓存设计
编辑
2024-09-18
💌中间键
00
请注意，本文编写于 274 天前，最后修改于 225 天前，其中某些信息可能已经过时。

目录

11.1 缓存的收益和成本
11.2 缓存更新策略
11.2.1 LRU/LFU/FIFO 算法剔除
11.2.2 超时剔除
11.2.3 主动更新
11.2.4 最佳实践
11.3 缓存粒度控制
11.4 穿透优化
如何解决缓存穿透问题：
11.5 无底洞优化
11.6 雪崩优化
11.7 热点key重建优化
11.7.1 互斥锁
11.7.2 永远不过期

11.1 缓存的收益和成本

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

image.png 收益如下：

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

成本如下：

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

缓存的使用场景基本包含如下几种：

  • 开销大的复杂计算：以MySQL为例子，一些复杂的操作或者计算（例如大量联表操作、一些分组计算），如果不加缓存，不但无法满足高并发量，同时也会给mysql带来巨大的负担
  • 加速请求相应：即使查询单条后端数据足够快（例如select * from table where id=），那么依然可以使用缓存，以Redis为例，每秒可以完成数万次读写，并且提供的批量操作可以优化整个IO链的响应时间。

11.2 缓存更新策略

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

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

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

11.2.1 LRU/LFU/FIFO 算法剔除

  • 使用场景：通常用于缓存使用量超过了预设的最大值的时候，如何对现有的数据进行剔除。例如Redis使用MaxMemory-policy这个配置作为内存最大值后对于数据的剔除策略
  • 一致性：要清理哪些数据是有具体算法决定，开发人员只能决定使用哪种算法，所以数据的一致性是最差的。
  • 维护成本：算法不需要开发人员自己来实现，通常只需要配置最大maxmemory和对应的策略即可。开发人员只需要知道每种算法的含义，选择适合自己的算法即可。

11.2.2 超时剔除

  • 使用场景：通过给缓存数据设置过期时间，让其在过期时间后自动删除，例如Redis提供的expire命令。如果业务可以容忍一段时间内，缓存层数据和存储层数据不一致，那么可以为其设置过期时间。在数据过期后，再从真实数据获取数据，重新放到缓存并设置过期时间。例如一个视频的描述信息，可以容忍几分钟内数据不一致，但是涉及交易方面的业务，后果可想而知。
  • 一致性：一段时间窗口内（取决于过期时间长短）存在一致性问题，即缓存数据和真实数据源的数据不一致。
  • 维护成本：不是很高，只需要设置expire过期时间即可

11.2.3 主动更新

  • 使用场景：应用方对于数据的一致性要求很高，需要在真实数据更新后，立即更新缓存数据。例如可以利用消息系统或者其他方式通知缓存更新。
  • 一致性：最高，但如果主动更新发生了问题，那么这条数据很可能长时间不会更新，所以建议结合超时剔除一起使用效果会更好
  • 维护成本：较高，需要自己来完成更新，并保证更新操作的准确性。

11.2.4 最佳实践

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

image.png

11.3 缓存粒度控制

图11-2是很多项目关于缓存比较常用的选型，缓存层选用Redis，存储 层选用MySQL。

image.png

例如现在需要将MySql的用户信息使用Redis缓存，可以执行如下操作：

  1. 从MySQl获取用户信息
sql
select * from user where id = {id};
  1. 将用户信息存储到Redis中
redis
set user:{id} 'select * from user where id ={id}'
  1. 假设用户有100列，需要缓存到什么维度呢？
    • 缓存全部列
    redis
    set user:{id} 'select * from user where id ={id}'
    • 缓存部分重要列
    redis
    set user:{id} 'select {importColumn1},{import Column2} ……from user where id ={id}'

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

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

image.png

11.4 穿透优化

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

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

缓存穿透的问题后果：

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

造成缓存穿透的原因：

  1. 自身业务代码或者数据出现问题
  2. 一些恶意工具、爬虫等造成大量空命中

如何解决缓存穿透问题：

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

image.png

image.png

缓存空对象有两个问题：

  1. 空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间，比较有效的是针对这类数据设置一个较短的过期时间，让其自动剔除。
  2. 缓存层和存储层的数据有一段时间的窗口不一致，可能会对业务有一定影响。

例如过期时间设置为5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他地方清除掉缓存层中的空对象。

java
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;
    }
}
  1. 布隆过滤器拦截

如图11-5所示，在访问缓存层和存储层之前，将存在的key用布隆过滤器提前保存起来，做第一层拦截。

例如：一个推荐系统有4亿个用户id，每 个小时算法工程师会根据每个用户之前历史行为计算出推荐数据放到存储层中，

但是最新的用户由于没有历史行为，就会发生缓存穿透的行为，为此可 以将所有推荐数据的用户做成布隆过滤器。

如果布隆过滤器认为该用户id不存在，那么就不会访问存储层，在一定程度保护了存储层。

image.png

相关信息

有关布隆过滤器的相关知识，可以参 考：https://en.wikipedia.org/wiki/Bloom_filter可以利用Redis的Bitmaps实现布 隆过滤器，GitHub上已经开源了类似的方案，读者可以进行参 考：https://github.com/erikdubbelboer/redis-lua-scaling-bloom-filter。

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

image.png

11.5 无底洞优化

2010年，Facebook的Memcache节点已经达到了3000个，承载着TB级别的缓存数据。

但开发和运维人员发现了一个问题，为了满足业务要求添加了 大量新Memcache节点，但是发现性能不但没有好转反而下降了，当时将这种现象称为缓存的“无底洞”现象。

那么为什么会产生这种现象呢?

通常来说添加节点使得Memcache集群性能应该更强了，但事实并非如此。

键值数据库由于通常采用哈希函数将key映射到各个节点上，造成key的分布与业务无关，但是由于数据量和访问量的持续增长，造成需要添加大量节点做水平扩容，

导致键值分布到更多的节点上，所以无论是Memcache还是Redis的分布式，批量操作通常需要从不同节点上获取，

相比于单机批量操作只涉及一次网络操作，分布式批量操作会涉及多次网络时间。

图11-6展示了在分布式条件下，一次mget操作需要访问多个Redis节点，需要多次网络时间。

image.png 而图11-7由于所有键值都集中在一个节点上，所以一次批量操作只需要一次网络时间。

image.png

无底洞问题分析：

  • 客户端一次批量操作会涉及多次网络操作，也就意味着批量操作会随着节点的增多，耗时会不断增大。
  • 网络连接数变多，对节点的性能也有一定影响。

下面介绍如何在分布式条件下优化批量操作。在介绍具体的方法之前，我们来看一下常见的IO优化思路：

  1. 命令本身的优化，例如优化SQL语句等。
  2. 减少网络通信次数。
  3. 降低接入成本，例如客户端使用长连/连接池、NIO等。这里我们假设命令、客户端连接已经为最优，重点讨论减少网络操作次数。

image.png

image.png

上面已经给出了IO的优化思路以及单个节点的批量操作优化方式，

下面我们将结合Redis Cluster的一些特性对四种分布式的批量操作方式进行说明

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

image.png

java
List<String> serialMGet(List<String> keys) {
    // 结果集
    List<String> values = new ArrayList<String>();
    // n次串行get
    for (String key : keys) {
        String value = jedisCluster.get(key);
        values.add(value);
    }
    return values;
}
  1. 串行IO Redis Cluster使用CRC16算法计算出散列值，再取对16383的余数就可以算出slot值，

同时10.5节我们提到过Smart客户端会保存slot和节点的对应关系，有了这两个数据就可以将属于同一个节点的key进行归档，得到每个节点的key子列表，

之后对每个节点执行mget或者Pipeline操作，它的操作时间=node次网络时间+n次命令时间，网络次数是node的个数，整个过程如图11- 10所示，很明显这种方案比第一种要好很多，但是如果节点数太多，还是有一定的性能问题。

image.png

java
Map<String, String> serialIOMget(List<String> keys) {
    // 结果集
    Map<String, String> keyValueMap = new HashMap<String, String>();
    // 属于各个节点的key列表,JedisPool要提供基于ip和port的hashcode方法
    Map<JedisPool, List<String>> nodeKeyListMap = new HashMap<JedisPool, List<String>>();
    // 遍历所有的key
    for (String key : keys) {
        // 使用CRC16本地计算每个key的slot
        int slot = JedisClusterCRC16.getSlot(key);
        // 通过jedisCluster本地slot->node映射获取slot对应的node
        JedisPool jedisPool = jedisCluster.getConnectionHandler().getJedisPoolFrom
        Slot(slot);
        // 归档
        if (nodeKeyListMap.containsKey(jedisPool)) {
            nodeKeyListMap.get(jedisPool).add(key);
        } else {
            List<String> list = new ArrayList<String>();
            list.add(key);
            nodeKeyListMap.put(jedisPool, list);
        }
    }
    // 从每个节点上批量获取，这里使用mget也可以使用pipeline
        for (Entry<JedisPool, List<String>> entry : nodeKeyListMap.entrySet()) {
        JedisPool jedisPool = entry.getKey();
        List<String> nodeKeyList = entry.getValue();
        // 列表变为数组
        String[] nodeKeyArray = nodeKeyList.toArray(new String[nodeKeyList.size()]);
        // 批量获取，可以使用mget或者Pipeline
        List<String> nodeValueList = jedisPool.getResource().mget(nodeKeyArray);
        // 归档
        for (int i = 0; i < nodeKeyList.size(); i++) {
            keyValueMap.put(nodeKeyList.get(i), nodeValueList.get(i));
        }
    }
    return keyValueMap;
}
  1. 并行IO 此方案是将方案2中的最后一步改为多线程执行，网络次数虽然还是节 点个数，但由于使用多线程网络时间变为O（1），这种方案会增加编程的 复杂度。它的操作时间为：
max_slow(node网络时间)+n次命令时间

java
Map<String, String> parallelIOMget(List<String> keys) {
    // 结果集
    Map<String, String> keyValueMap = new HashMap<String, String>();
    // 属于各个节点的key列表
    Map<JedisPool, List<String>> nodeKeyListMap = new HashMap<JedisPool, List<String>>();
    ...和前面一样
    // 多线程mget，最终汇总结果
    for (Entry<JedisPool, List<String>> entry : nodeKeyListMap.entrySet()) {
        // 多线程实现
    }
    return keyValueMap;
}

image.png

  1. hash_tag实现 10.5节介绍了Redis Cluster的hash_tag功能，它可以将多个key强制分配到 一个节点上，它的操作时间=1次网络时间+n次命令时间，如图11-12所示。

image.png

image.png

java
List<String> hashTagMget(String[] hashTagKeys) {
    return jedisCluster.mget(hashTagKeys);
}

image.png

11.6 雪崩优化

图11-14描述了什么是缓存雪崩：由于缓存层承载着大量请求，有效地 保护了存储层，但是如果缓存层由于某些原因不能提供服务，于是所有的请 求都会达到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情 况。

缓存雪崩的英文原意是stampeding herd（奔逃的野牛），指的是缓存层宕掉后，流量会像奔逃的野牛一样，打向后端存储。

image.png

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

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

  2. 依赖隔离组件为后端限流并降级。

    • 无论是缓存层还是存储层都会有出错的概率，可以将它们视同为资源。

    • 作为并发量较大的系统，假如有一个资源不可用，可能会造成线程全部阻塞（hang）在这个资源上，造成整个系统不可用。

    • 降级机制在高并发系统中是非常普遍的：比如推荐服务中，如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成前端页面是开天窗。

    • 在实际项目中，我们需要对重要的资源（例如Redis、MySQL、HBase、外部接口）都进行隔离，让每种资源都单独运行在自己的线程池中，即使个别资源出现了问题，对其他服务没有影响。

    • 但是线程池如何管理，比如如何关闭资源池、开启资源池、资源池阀值管理，这些做起来还是相当复杂的。这里推荐一个Java依赖隔离工具Hystrix（https://github.com/netflix/hystrix) 图11-15所示。Hystrix是解决依赖隔离的利器，但是该内容已经超出本书的范围，同时只适用于Java应用

image.png

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

11.7 热点key重建优化

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

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

在缓存失效的瞬间，有大量线程来重建缓存（如图11-16所示），造成后端负载加大，甚至可能会让应用崩溃。

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

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

11.7.1 互斥锁

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

image.png 下面代码使用Redis的setnx命令实现上述功能：

java
String get(String key) {
    // 从Redis中获取数据
    String value = redis.get(key);
    // 如果value为空，则开始重构缓存
    if (value == null) {
        // 只允许一个线程重构缓存，使用nx，并设置过期时间ex
        String mutexKey = "mutext:key:" + key;
        if (redis.set(mutexKey, "1", "ex 180", "nx")) {
            // 从数据源获取数据
            value = db.get(key);
            // 回写Redis，并设置过期时间
            redis.setex(key, timeout, value);
            // 删除key_mutex
            redis.delete(mutexKey);
        }
        // 其他线程休息50毫秒后重试
        else {
            Thread.sleep(50);
            get(key);
        }
    }
    return value;
}
  • 1）从Redis获取数据，如果值不为空，则直接返回值；否则执行下面的2.1）和2.2）步骤。
  • 2.1）如果set（nx和ex）结果为true，说明此时没有其他线程重建缓存，那么当前线程执行缓存构建逻辑。
  • 2.2）如果set（nx和ex）结果为false，说明此时已经有其他线程正在执行构建缓存的工作，那么当前线程将休息指定时间（例如这里是50毫秒，取决于构建缓存的速度）后，重新执行函数，直到获取到数据。

11.7.2 永远不过期

“永远不过期”包含两层意思：

  • 从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期后产生的问题，也就是“物理”不过期。
  • 从功能层面来看，为每个value设置一个逻辑过期时间，当发现超过逻过期时间后，会使用单独的线程去构建缓存。

image.png

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

下面代码使用Redis进行模拟：

java
String get(final String key) {
    V v = redis.get(key);
    String value = v.getValue();
    // 逻辑过期时间
    long logicTimeout = v.getLogicTimeout();
    // 如果逻辑过期时间小于当前时间，开始后台构建
    if (v.logicTimeout <= System.currentTimeMillis()) {
        String mutexKey = "mutex:key:" + key;
        if (redis.set(mutexKey, "1", "ex 180", "nx")) {
            // 重构缓存
            threadPool.execute(new Runnable() {
                public void run() {
                String dbValue = db.get(key);
                redis.set(key, (dbvalue,newLogicTimeout));
                redis.delete(mutexKey);
                }
                });
            }
        }
    return value;
    }

作为一个并发量较大的应用，在使用缓存时有三个目标：

  • 第一，加快用户访问速度，提高用户体验。
  • 第二，降低后端负载，减少潜在的风险，保证系统平稳。
  • 第三，保证数据“尽可能”及时更新。

image.png

本文作者:Eric

本文链接:

版权声明:本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！