《Redis开发与运维》---- 缓存设计

一、缓存的收益和成本分析

• 收益：加速读写，降低后端负载
• 成本：数据不一致性，代码维护成本，运维成本

缓存的使用场景：

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

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

二、缓存更新策略（三种）

1. LRU/LFU/FIFO算法剔除：剔除算法通常用于缓存使用量超过了预设的最大值时候，如何对现有的数据进行剔除。Redis使用maxmemory-policy配置。
2. 超时剔除：通过给缓存数据设置过期时间，让其在过期时间后 自动删除。
3. 主动更新：应用方对于数据的一致性要求高，需要在真实数据更新后， 立即更新缓存数据。
   

实践建议

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

三、缓存粒度控制方法

缓存粒度问题：究竟是缓存全部属性还是只缓存部分 重要属性呢？

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

四、缓存穿透

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

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

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

解决缓存穿透：

1. 缓存空对象：当存储层不命中后，仍然将空对象保留到缓存层 中，之后再访问这个数据将会从缓存中获取，这样就保护了后端数据源。
   缓存空对象会有两个问题：
   第一，空值做了缓存，意味着缓存层中存了 更多的键，需要更多的内存空间（如果是攻击，问题更严重），比较有效的 方法是针对这类数据设置一个较短的过期时间，让其自动剔除。
   第二，缓存 层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。

2. 布隆过滤器拦截
   在访问缓存层和存储层之前，将存在的key用布隆过滤 器提前保存起来，做第一层拦截。
   这种方法适用于数据命中不高、数据相对固定、实时性低（通常是数据 集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。
   3.两种方法对比
   

五、无底洞问题优化

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

无论是Memcache还是Redis的分布式，批量操作通常需要从不 同节点上获取，相比于单机批量操作只涉及一次网络操作，分布式批量操作 会涉及多次网络时间。

常见的IO优化思路：

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

这里我们假设命令、客户端连接已经为最优，重点讨论减少网络操作次数。以Redis批量获取n个字符串为例，有三种实现方法：

• 客户端n次get：n次网络+n次get命令本身。
• 客户端1次pipeline get：1次网络+n次get命令本身。
• 客户端1次mget：1次网络+1次mget命令本身。

Redis Cluster四种分布式的批量操作方式

1. 串行命令：它的操作时间=n次网络时间+n次命令时间，网络次数是n。很显然这种方案不是最优的，但是实现起来比较简单。
2. 串行IO：Redis Cluster使用CRC16算法计算出散列值，再取对16383的余数就可以算出slot值，同时10.5节我们提到过Smart客户端会保存slot和节点的对应关系，有了这两个数据就可以将属于同一个节点的key进行归档，得到每个节 点的key子列表，之后对每个节点执行mget或者Pipeline操作，它的操作时间 =node次网络时间+n次命令时间，网络次数是node的个数，整个过程如图11- 10所示，很明显这种方案比第一种要好很多，但是如果节点数太多，还是有 一定的性能问题。
3. 并行IO：此方案是将方案2中的最后一步改为多线程执行，网络次数虽然还是节点个数，但由于使用多线程网络时间变O(1)，这种方案会增加编程的复杂度。
4. hash_tag实现：Redis Cluster的hash_tag功能，它可以将多个key强制分配到 一个节点上，它的操作时间=1次网络时间+n次命令时间
   

六、缓存雪崩

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

预防和解决缓存雪崩问题：

1. 保证缓存层服务高可用性：Redis Sentinel和Redis Cluster都实现了高可用。
2. 依赖隔离组件为后端限流并降级：推荐一个Java依赖隔离工具 Hystrix（https://github.com/netflix/hystrix）
3. 提前演练：在项目上线前，演练缓存层宕掉后，应用以及后端的负 载情况以及可能出现的问题，在此基础上做一些预案设定。

七、热点key重建优化（缓存击穿）

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

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

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

解决方法：

1. 互斥锁（mutex key）：此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行 完，重新从缓存获取数据即可。
2. 永远不过期
   “永远不过期”包含两层意思： 从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期 后产生的问题，也就是“物理”不过期。 从功能层面来看，为每个value设置一个逻辑过期时间，当发现超过逻 辑过期时间后，会使用单独的线程去构建缓存。
   从实战看，此方法有效杜绝了热点key产生的问题，但唯一不足的就是重构缓存期间，会出现数据不一致的情况，这取决于应用方是否容忍这种不 一致。