【Redis—进阶】缓存设计

缓存的收益和成本

收益

• 加速读写：由于缓存一般都是全内存的（例如Redis、Memcache），而存储层一般读写性能不够强悍（例如MySQL），经过缓存的使用能够有效地加速读写，优化用户体验。
• 下降后端负载：帮助后端减小访问量和复杂计算（例如很复杂的SQL语句），在很大程度下降了后端的负载。

成本

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

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

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

缓存更新策略

LRU/LFU/FIFO算法剔除

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

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

维护成本：算法不须要开发人员本身来实现，一般只须要配置最大maxmemory和对应的策略便可。开发人员只须要知道每种算法的含义，选择适合本身的算法便可。

超时剔除

使用场景：超时剔除经过给缓存数据设置过时时间，让其在过时时间后自动删除，例如Redis提供的expire命令。若是业务能够容忍一段时间内，缓存层数据和存储层数据不一致，那么能够为其设置过时时间。在数据过时后，再从真实数据源获取数据，从新放到缓存并设置过时时间。

一致性：一段时间窗口内存在一致性问题，即缓存数据非和真实数据源的数据不一致。

维护成本：维护成本不是很高，只需设置expire过时时间便可，固然前提是应用方容许这段时间可能发生的数据不一致。

主动更新

使用场景：应用方对于数据的一致性要求高，须要在真实数据更新后，当即更新缓存数据。例如能够利用消息系统或者其余方式通知缓存更新。

一致性：一致性最高，但若是主动更新发生了问题，那么这条数据极可能很长时间不会更新，因此建议结合超时剔除一块儿使用效果会更好。

维护成本：维护成本会比较高，开发者须要本身来完成更新，并保证更新操做的正确性。

最佳实践

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

缓存粒度控制

例如如今须要将MySQL的用户信息使用Redis缓存，假设用户表有100个列，须要缓存到什么维度呢？这个问题就是缓存粒度问题，到底是缓存所有属性仍是只缓存部分重要属性？下面将从通用性、空间占用、代码维护三个角度进行说明。

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

空间占用：缓存所有数据要比部分数据占用更多的空间，可能存在如下问题：

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

代码维护：所有数据的优点更加明显，而部分数据一旦要加新字段须要修改业务代码，并且修改后一般还须要刷新缓存数据。

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

缓存穿透

缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，一般出于容错的考虑，若是从存储层查不到数据则不写入缓存层。缓存穿透将致使不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。

缓存穿透问题可能会使后端存储负载加大，因为不少后端存储不具有高并发性，甚至可能形成后端存储宕掉。一般能够在程序中分别统计总调用数、缓存层命中数、存储层命中数，若是发现大量存储层空命中，可能就是出现了缓存穿透问题。

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

缓存空对象

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

缓存空对象会有两个问题：

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

布隆过滤器拦截

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

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

缓存空对象和布隆过滤器方案对比

缓存无底洞

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

那么为何会产生这种现象呢，一般来讲添加节点使得Memcache集群性能应该更强了，但事实并不是如此。键值数据库因为一般采用哈希函数将key映射到各个节点上，形成key的分布与业务无关，可是因为数据量和访问量的持续增加，形成须要添加大量节点作水平扩容，致使键值分布到更多的节点上，因此不管是Memcache仍是Redis的分布式，批量操做（例如mget）一般须要从不一样节点上获取，相比于单机批量操做只涉及一次网络操做，分布式批量操做会涉及屡次网络时间。

无底洞问题分析：

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

用一句通俗的话总结就是，更多的节点不表明更高的性能，所谓“无底洞”就是说投入越多不必定产出越多。可是分布式又是不能够避免的，由于访问量和数据量愈来愈大，一个节点根本抗不住，因此如何高效地在分布式缓存中批量操做是一个难点。

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

• 命令自己的优化，例如优化SQL语句等。
• 减小网络通讯次数。
• 下降接入成本，例如客户端使用长连/链接池、NIO等。

这里咱们假设命令、客户端链接已经为最优，重点讨论减小网络操做次数。以Redis批量获取n个字符串为例，咱们将结合Redis Cluster的一些特性对四种分布式的批量操做方式进行说明。

串行命令

因为n个key通常来讲都分布在Redis Cluster的各个节点上，所以没法使用mget命令一次性获取，因此一般来说要获取n个key的值，最简单的方法就是逐次执行n个get命令，这种操做时间复杂度较高，它的操做时间=n次网络时间+n次命令时间，网络次数是n。很显然这种方案不是最优的，可是实
现起来比较简单。

串行IO

Redis Cluster使用CRC16算法计算出散列值，再取对16383的余数就能够算出slot值，同时Smart客户端会保存slot和节点的对应关系，有了这两个数据就能够将属于同一个节点的key进行归档，获得每一个节点的key子列表，以后对每一个节点执行mget或者Pipeline操做，它的操做时间=node次网络时间+n次命令时间，网络次数是node的个数，很明显这种方案比第一种要好不少，可是若是节点数太多，仍是有必定的性能问题。

并行IO

此方案是将方案2中的最后一步改成多线程执行，网络次数虽然仍是节点个数，但因为使用多线程网络时间变为O（1），这种方案会增长编程的复杂度。它的操做时间为：max_slow(node次网络时间 )+n次命令时间。

hash_tag实现

使用Redis Cluster的hash_tag功能，它能够将多个key强制分配到一个节点上，它的操做时间=1次网络时间+n次命令时间。

方案对比

缓存雪崩

因为缓存层承载着大量请求，有效地保护了存储层，可是若是缓存层因为某些缘由不能提供服务，因而全部的请求都会达到存储层，存储层的调用量会暴增，形成存储层也会级联宕机的状况。

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

保证缓存层服务高可用性

若是缓存层设计成高可用的，即便个别节点、个别机器、甚至是机房宕掉，依然能够提供服务，例如Redis Sentinel和Redis Cluster都实现了高可用。

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

不管是缓存层仍是存储层都会有出错的几率，能够将它们视同为资源。做为并发量较大的系统，假若有一个资源不可用，可能会形成线程所有阻塞在这个资源上，形成整个系统不可用。

降级机制在高并发系统中是很是广泛的：好比推荐服务中，若是个性化推荐服务不可用，能够降级补充热点数据。在实际项目中，咱们须要对重要的资源（例如Redis、MySQL、HBase、外部接口）都进行隔离，让每种资源都单独运行在本身的线程池中，即便个别资源出现了问题，对其余服务没有影响。可是线程池如何管理，好比如何关闭资源池、开启资源池、资源池阀值管理，这些作起来仍是至关复杂的。

提早演练

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

热点key重建

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

• 当前key是一个热点key，并发量很是大。
• 重建缓存不能在短期完成，多是一个复杂计算，例如复杂的SQL、屡次IO、多个依赖等。

在缓存失效的瞬间，有大量线程来重建缓存，形成后端负载加大，甚至可能会让应用崩溃。要解决这个问题也不是很复杂，可是不能为了解决这个问题给系统带来更多的麻烦，因此须要制定以下目标：

• 减小重建缓存的次数。
• 数据尽量一致。
• 较少的潜在危险。

互斥锁

此方法只容许一个线程重建缓存，其余线程等待重建缓存的线程执行完，从新从缓存获取数据便可。例如可使用Redis的setnx命令来实现一个简单的分布式互斥锁来完成。

永远不过时

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

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

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

总结

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