关于redis: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 产生的问题，但惟一有余的就是重构缓存期间，会呈现数据不统一的状况，这取决于利用方是否容忍这种不统一。

总结

作为一个并发量较大的利用，在应用缓存时有三个指标：第一，放慢用户访问速度，进步用户体验。第二，升高后端负载，缩小潜在的危险，保证系统安稳。第三，保证数据“尽可能”及时更新。下表是依照这三个维度对上述两种解决方案所进行的比照。