Redis之缓存设计

　　缓存能够有效地加速应用的读写速度，同时也可以降低后端负载，对日常应用的开发至关重要。但是将缓存加入应用架构后也会带来一些问题，本章将针对这些问题介绍缓存使用技巧和设计方案，包含如下内容：

□ 缓存的收益和成本分析。

□ 缓存更新策略的选择和使用场景。

□ 缓存粒度控制方法。

□ 穿透问题优化。

□ 无底洞问题优化。

□ 雪崩问题优化。

口 热点key重建优化。

1.缓存的收益和成本

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

　　收益如下:

□ 速读写：因为缓存通常都是全内存的（例如 Redi~memcache),而存储层通常读写性能不够强桿（例如 MySQL),通过缓存的使用可以有效地加速读写，优化用户体验。

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

　　成本如下:

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

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

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

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

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

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

2.缓存更新策略

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

　　1.LRU/LFU/FIFO算法剔除

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

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

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

　　2.超时剔除

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

　　一致性: 一段时间窗口内（取决于过期时间长短）存在一致性问题，即缓存数据和真实数据源的数据不一致。维护成本。维护成本不是很高，只需设置expire过期时间即可，当然前提是应用方允许这段时间可能发生的数据不一致。

　　3.主动更新

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

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

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

表11-1给出了缓存的三种常见更新策略的对比。
策略	一致性	维护成本
LRU/LRF/FIFO 算法剔除	最差	低
超时剔除	较差	较低
主动更新	强	高

　　4.最佳实践

　　有两个建议：

□ 低一致性业务建议配置最大内存和淘汰策略的方式使用。

□ 高一致性业务可以结合使用超时剔除和主动更新，这样即使主动更新出了问题，也能保证数据过期时间后删除脏数据。

3.缓存粒度控制

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

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

　　从MySQL获取用户信息:

select * from user where id = { id }

　　将用户信息缓存到Redis中:

set user:{id }  'select * from user where id = { id }'

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

□ 缓存全部列:

set user:{id} 'select * from user where id = { id }'

□ 缓存部分重要列:

set user: {id} 'select {importantColumn1},  {important Column2} . . .  {importantColumnN} from user where id = { id } '

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

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

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

□ 全部数据会造成内存的浪费。

□ 全部数据可能每次传输产生的网络流量会比较大，耗时相对较大，在极端情况下会阻塞网络。

□ 全部数据的序列化和反序列化的CPU开销更大。

　　代码维护: 全部数据的优势更加明显，而部分数据一旦要加新字段需要修改业务代码，

　　而且修改后通常还需要刷新缓存数据。

　　表11-2给出缓存全部数据和部分数据在通用性、空间占用、代码维护上的对比，开发人员可以酌情选择。

表11-2 缓存全部数据和部分数据对比
数据类型	通用性	空间占用（内存空间 + 网络带宽）	代码维护
全部数据	高	大	简单
部分数据	低	小	较为复杂

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

4.穿透优化

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

1) 缓存层不命中。

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

3) 返回空结果。

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

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

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

　　1.缓存空对象

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

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

　　2.布隆过滤器拦截

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

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

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

　　3.两种方案对比

　　前面介绍了缓存穿透问题的两种解决方法（实际上这个问题是一个开放问题，有很多解决方法)，下面通过表11-3从适用场景和维护成本两个方面对两种方案进行分析。

表 11-3 缓存空对象和布隆过滤器方案对比
解决缓存穿透	适用场景	维护成本
缓存空对象	数据命中不高 数据频繁变化实时性高	代码维护简单 需要过多的缓存空间 数据不一致
布隆过滤器	数据命中不高 数据相对固定实时性低	代码维护复杂 缓存空间占用少

5.无底洞优化

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

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

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

　　而图11-7由于所有键值都集中在一个节点上，所以一次批量操作只需要一次网络时间。无底洞问题分析：

□ 客户端一次批量操作会涉及多次网络操作，也就意味着批量操作会随着节点的增多，耗时会不断增大。

□ 网络连接数变多，对节点的性能也有一定影响。

　　用一句通俗的话总结就是，更多的节点不代表更高的性能，所谓“无底洞”就是说投入越多不一定产出越多。但是分布式又是不可以避免的，因为访问量和数据量越来越大，一个节点根本抗不住，所以如何高效地在分布式缓存中批量操作是一个难点。下面介绍如何在分布式条件下优化批量操作。在介绍具体的方法之前，我们来看一下常见的IO优化思路:

□ 命令本身的优化，例如优化 SQL 语句等。

□ 减少网络通信次数。

□ 降低接入成本，例如客户端使用长连/连接池、NIO等。

　　这里我们假设命令、客户端连接已经为最优，重点讨论减少网络操作次数。

　　以Redis 批量获取n个字符串为例，有三种实现方法，如图11-8 所示。

□ 客户端n次get:  n次网络 + n次 get 命令本身。

□ 客户端1次Pipeline get: 1次网络 + n次get命令本身。

□ 客户端1次 mget: 1次网络 + 1次 mget命令本身。

　　上面已经给出了IO的优化思路以及单个节点的批量操作优化方式，下面我们将结合Redis Cluster的一些特性对四种分布式的批量操作方式进行说明。

　　1.串行命令

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

　　2.串行IO

　　Redis Cluster使用CRC16算法计算出散列值，再取对16383的余数就可以算出slot值，同时10.5节我们提到过Smart客户端会保存slot和节点的对应关系，有了这两个数据就可以将属于同一个节点的 key 进行归档，得到每个节点的key子列表，之后对每个节点执行mget或者Pipeline操作，它的操作时间=node次网络时间 + n次命令时间，网络次数是node的个数，整个过程如图 11-10 所示，很明显这种方案比第一种要好很多，但是如果节点数太多，还是有一定的性能问题。

　　3.并行IO

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

　　整个过程如图11-11所示

　　4.hash_tag实现

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

　　如图11-13所示，所有key属于node2 节点。

　　上面已经对批量操作的四种方案进行了介绍，最后通过表11-4来对四种方案的优缺点、网络IO次数进行一个总结。

表 11-4 四种批量操作解决方案对比
方案	优点	缺点	网络IO
串行命令	1)编程简单 2)如果少量keys,性能可以满足要求	大量keys请求延迟严重	O(keys)
串行IO	1)编程简单 2)少量节点，性能满足要求	大量node 延迟严重	O(nodes)
并行IO	利用并行特性，延迟取决于最慢的节点	1)编程复杂 2)由于多线程，问题定位可能较难	O (max_slow(nodes))
hash_tag	性能最高	1)业务维护成本较高 2)容易出现数据倾斜	O(1)

　　实际开发中可以根据表11-4给出的优缺点进行分析，没有最好的方案只有最合适的方案。

6.雪崩优化

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

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

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

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

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

7.热点key重建优化

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

□ 当前key是一个热点key(例如一个热门的娱乐新闻)，并发量非常大。

□ 重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的SQL、多次10、多个依赖等。

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

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

　　□ 减少重建缓存的次数。

□ 数据尽可能一致。

□ 较少的潜在危险。

　　1.互斥锁(mutex key)

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

　　下面代码使用Redis的 setnx命令实现上述功能:

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毫秒，取决于构建缓存的速度）后,重新执行函数，直到获取到数据。

　　2.永远不过期

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

□ 从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期后产生的问题，也就是“物理”不过期。

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

　　整个过程如图11-18所示。

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

　　作为一个并发量较大的应用，在使用缓存时有三个目标：第一，加快用户访问速度，提高用户体验。第二，降低后端负载，减少潜在的风险，保证系统平稳。第三，保证数据“尽可能”及时更新。下面将按照这三个维度对上述两种解决方案进行分析。

□ 互斥锁（mutex key) : 这种方案思路比较简单，但是存在一定的隐患，如果构建缓存过程出现问题或者时间较长，可能会存在死锁和线程池阻塞的风险，但是这种方法能够较好地降低后端存储负载，并在一致性上做得比较好。

□ “永远不过期”：这种方案由于没有设置真正的过期时间，实际上已经不存在热点key产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。

　　两种解决方法对比如表11-5所示。

表11-5 两种热点key的解决方法
解决方案	优点	缺点
简单分布式锁	思路简单 保证一致性	代码复杂度增大 存在死锁的风险 存在线程池阻塞的风险
“永远不过期”	基本杜绝热点key问题	不保证一致性 逻辑过期时间增加代码维护成本和内存成本

8.总结

　　1.缓存的使用带来的收益是能够加速读写，降低后_端存储负载。

　　2.缓存的使用带来的成本是缓存和存储数据不一致性，代码维护成本增大，架构复杂度增大。

　　3.比较推荐的缓存更新策略是结合剔除、超时、主动更新三种方案共同完成。

　　4.穿透问题：使用缓存空对象和布隆过滤器来解决，注意它们各自的使用场景和局限性。

　　5.无底洞问题：分布式缓存中，有更多的机器不保证有更高的性能。有四种批量操作方式：串行命令、串行IO、并行IO、hash_tag。

　　6.雪崩问题：缓存层高可用、客户端降级、提前演练是解决雪崩问题的重要方法。

　　7.热点key问题：互斥锁、“永远不过期”能够在一定程度上解决热点key问题，开发人员在使用时要了解它们各自的使用成本。