关于redis:深入学习Redis之缓存设计与优化

缓存的应用与设计

缓存的收益与老本

收益：

• 减速读写：CPU L1/L2/L3 Cache、浏览器缓存等。因为缓存通常都是全内存的（例如 Redis、Memcache），而 存储层通常读写性能不够强悍（例如 MySQL），通过缓存的应用能够无效 地减速读写，优化用户体验。
• 升高后端负载：帮忙后端缩小访问量和简单计算，在很大水平升高了后端的负载。

老本：

• 数据不统一：缓存层和数据层有工夫窗口不统一，和更新策略无关。
• 代码保护老本：退出缓存后，须要同时解决缓存层和存储层的逻辑，增大了开发者保护代码的老本。
• 运维老本：以 Redis Cluster 为例，退出后无形中减少了运维老本。

应用场景：

• 升高后端负载：对高耗费的 SQL：join 后果集 / 分组统计后果缓存。
• 减速申请响应：利用 Redis/Memcache 优化 IO 响应工夫。
• 大量写合并为批量写：比方计数器先 Redis 累加再批量写入 DB。

缓存更新策略

缓存中的数据通常都是有生命周期的，须要在指定工夫后被删除或更新，这样能够保障缓存空间在一个可控的范畴。

然而缓存中的数据会和数据源中的实在数据有一段时间窗口的不统一，须要 利用某些策略进行更新。

上面将别离从应用场景、一致性、开发人员开发 / 保护老本三个方面介绍三种缓存的更新策略。

LRU/LFU/FIFO 算法剔除

LRU：Least Recently Used，最近起码应用。

LFU：Least Frequently Used，最不常常应用。

FIFO：First In First Out，先进先出。

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

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

保护老本 ：算法不须要开发人员本人来实现，通常只须要配置最大maxmemory 和对应的策略 即可。

超时剔除

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

一致性：一段时间窗口内（取决于过期工夫长短）存在一致性问题，即缓存数据和实在数据源的数据不统一。

保护老本：保护老本不是很高，只需设置 expire 过期工夫即可，当然前提是利用方容许这段时间可能产生的数据不统一。

被动更新

应用场景 ：利用方对于数据的一致性要求高， 须要在实在数据更新后，立刻更新缓存数据。例如能够利用音讯零碎或者其余形式告诉缓存更新。

一致性 ：一致性最高，但如果被动更新产生了问题，那么这条数据很可能很长时间不会更新，所以倡议 联合超时剔除 一起应用成果会更好。

保护老本：保护老本会比拟高，开发者须要本人来实现更新，并保障更新操作的正确性。

总结

倡议：

• 低一致性业务 倡议配置最大内存和淘汰策略的形式应用。
• 高一致性业务 能够联合应用超时剔除和被动更新，这样即便被动更新出了问题，也能保证数据过期工夫后删除脏数据。

缓存粒度管制

个别罕用的架构就是缓存层应用 Redis，存储层应用 MySQL。

比方：咱们当初须要缓存用户信息。

第一步：从 MySQL 查问，失去后果。

第二步：放入缓存中。

然而，咱们是缓存 MySQL 查出的所有列呢，还是某一些比拟重要罕用的列。

上述这个问题就是缓存粒度问题。

上面将从 通用性 、 空间占用 、 代码保护 三个角度进行阐明：

• 通用性：缓存全副数据比局部数据更加通用，但从理论教训看，很长时间内利用只须要几个重要的属性。

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

  • 全副数据会造成内存的节约。
  • 全副数据可能每次传输产生的网络流量会比拟大，耗时绝对较大，在极其状况下会阻塞网络。
  • 全副数据的序列化和反序列化的 CPU 开销更大。
• 代码保护：全副数据的劣势更加显著，而局部数据一旦要加新字段须要批改业务代码，而且批改后通常还须要刷新缓存数据。

缓存穿透问题

缓存穿透是指 查问一个基本不存在的数据，缓存层和存储层都不会命中，通常出于容错的思考，如果从存储层查不到数据则不写入缓存层。分为以下三步：

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

缓存穿透带来的问题：

• 缓存穿透将导致不存在的数据每次申请都要到存储层去查问，失去了缓存爱护后端存储的意义。
• 缓存穿透问题可能会 使后端存储负载加大，因为很多后端存储不具备高并发性，甚至可能造成后端存储宕掉。通常能够在程序中别离统计总调用数、缓存层命中数、存储层命中数，如果发现大量存储层空命中，可能就是呈现了缓存穿透问题。

造成缓存穿透的起因：

• 业务代码本身问题。
• 一些歹意攻打、爬虫等。

穿透优化的计划：

• 缓存空对象。
• 布隆过滤器。

缓存空对象

其实也就是当第 2 步存储层没有命中后，依然将空对象保留到缓存层中，之后再拜访这个数据将会从缓存中获取。

这样会带来两种问题：

1. 空值做了缓存存储。意味着 缓存中须要更多的内存空间。所以咱们还须要针对这种空值减少一个过期工夫，例如 1 分钟，3 分钟等等。具体还是依据业务来判断。
2. 这样做后会造成短期内缓存层与存储层有一段时间数据不统一问题，可能会对业务有所影响，比方咱们查问商品 ID 为 888，此时缓存层和存储层都没有此 ID 数据，咱们进行空值缓存后，如果此时恰好增加了 ID 为 888 的数据，就会导致短期内不统一问题。此时能够 利用音讯零碎或者其余形式革除掉缓存层中的空对象。

布隆过滤器

布隆过滤器是在拜访缓存层和存储层之前，将存在的 key 用布隆过滤器提前保存起来，做第一层拦挡。

这种办法 实用于数据命中不高、数据绝对固定、实时性低（通常是数据集较大）的利用场景，代码保护较为简单，然而缓存空间占用少。

缓存雪崩问题

因为 Cache 服务承载大量的申请，当 Cache 服务宕机后，大量的流量会间接压向后端组件 DB，造成级联故障。

优化计划

1. 保障缓存高可用性，就算个别节点挂掉，仍然还有别的能够提供服务。
2. 依赖隔离组件为后端限流降级，比方应用 Hystrix。
3. 提前演练。

无底洞问题

2010 年，Facebook 的 Memcache 节点曾经达到了 3000 个，承载着 TB 级别的缓存数据。但开发和运维人员发现了一个问题，为了满足业务要求 增加了大量新 Memcache 节点，然而发现性能岂但没有恶化反而降落了，过后将这种景象称为缓存的“无底洞”景象。

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

优化思路

• 命令自身的优化，例如：keys、hgetall、bigkey 等。
• 缩小网络通信次数。
• 升高接入老本，例如客户端应用长连贯 / 连接池、NIO 等。

咱们上面重点 如何升高网络通信次数。

串行 mget

因为 n 个 key 是比拟平均地散布在 Redis Cluster 的各个节点上，因而无奈应用 mget 命令一次性获取，所以通常来讲要获取 n 个 key 的值，最简略的办法就是逐次执行 n 个 get 命令，这种操作 工夫复杂度较高 ，它的 操作工夫 =n 次网络工夫 +n 次命令工夫。n 是 key 的数量，是最简略的实现形式但显然不是最优的。

串行 IO

Redis Cluster 应用 CRC16 算法计算出散列值，再取对 16383 的余数就能够算出 slot 值，有了这两个数据就能够 将属于同一个节点的 key 进行归档，失去每个节点的 key 子列表，之后对每个节点执行 mget 或者 Pipeline 操作。

它的 操作工夫 =node 次网络工夫 +n 次命令工夫。

这种计划比第一种要好一点，然而 如果节点数太多，还是有肯定的性能问题。

并行 IO

此计划是将计划 2 中的最初一步改为多线程执行，网络次数尽管还是节点个数，但因为应用多线程网络工夫变为 O(1)，这种计划会减少编程的复杂度。操作工夫为max_slow(node 网络工夫)+n 次命令工夫。

HASH_TAG

Redis Cluster 的 hash_tag 性能能够强制将多个 key 强制调配到 一个节点上，它的操作工夫=1 次网络工夫 +n 次命令工夫。

四种思路总结

热点 key 的重建优化

咱们通常应用的“缓存 + 过期工夫”的策略既能够减速数据读写，又保证数据的定期更新，这种模式根本可能满足绝大部分需要。然而 有两个问题如果同时呈现，可能就会对利用造成致命的危害：

• 以后 key 是一个 热点 key（例如一个热门的娱乐新闻），并发量十分大。
• 重建缓存 不能在短时间实现，可能是一个简单计算。

在缓存生效的霎时，有大量线程来重建缓存，造成后端负载加大，甚至可能会让利用解体。

咱们须要制订如下指标：

• 缩小重建缓存的次数。
• 数据尽可能统一。
• 缩小潜在危险。

上面咱们解说一下两种解决方案。

互斥锁

此办法 只容许一个线程重建缓存，其余线程期待重建缓存的线程执行完后，再从新从缓存获取数据即可。

咱们能够应用 Redis 的 setnx 命令来实现互斥锁。

1. 如果 Redis 数据存在则返回，不存在就进入第二步。
2. 如果 setnx 后果为 true，阐明没有其它线程重建，咱们执行重建缓存逻辑。
3. 如果 setnx 后果为 false，阐明有其它的线程正在重建缓存，以后线程能够睡眠指定工夫后再去获取缓存数据。

永远不过期

缓存层面：没有设置过期工夫。

性能层面：为每个 value 设置一个逻辑过期工夫，当发现超过逻辑过期工夫后，会应用独自的线程去构建缓存。

此办法能够无效杜绝了热点 key 产生的问题，但 惟一有余的就是重构缓存期间，会呈现数据不统一的状况，这取决于是否能够容忍这种不统一。

两种计划比照