文章目录
一、缓存的收益和成本分析
- 收益:加速读写,降低后端负载
- 成本:数据不一致性,代码维护成本,运维成本
缓存的使用场景:
-
开销大的复杂计算:以MySQL为例子,一些复杂的操作或者计算(例 如大量联表操作、一些分组计算),如果不加缓存,不但无法满足高并发 量,同时也会给MySQL带来巨大的负担。
-
加速请求响应:即使查询单条后端数据足够快(例如select*from table where id=),那么依然可以使用缓存,以Redis为例子,每秒可以完成数万次读写,并且提供的批量操作可以优化整个IO链的响应时间。
二、缓存更新策略(三种)
- LRU/LFU/FIFO算法剔除:剔除算法通常用于缓存使用量超过了预设的最大值时候,如何对现有的数据进行剔除。Redis使用
maxmemory-policy
配置。 - 超时剔除:通过给缓存数据设置过期时间,让其在过期时间后 自动删除。
- 主动更新:应用方对于数据的一致性要求高,需要在真实数据更新后, 立即更新缓存数据。
实践建议
- 低一致性业务建议配置最大内存和淘汰策略的方式使用。
- 高一致性业务可以结合使用超时剔除和主动更新,这样即使主动更新 出了问题,也能保证数据过期时间后删除脏数据。
三、缓存粒度控制方法
缓存粒度问题:究竟是缓存全部属性还是只缓存部分 重要属性呢?
缓存粒度问题是一个容易被忽视的问题,如果使用不当,可能会造成很 多无用空间的浪费,网络带宽的浪费,代码通用性较差等情况,需要综合数据通用性、空间占用比、代码维护性三点进行取舍。
四、缓存穿透
缓存穿透是指查询一个根本不存在的数据,缓存层和存储层都不会命中,通常出于容错的考虑,如果从存储层查不到数据则不写入缓存层,如图 11-3所示。
缓存穿透将导致不存在的数据每次请求都要到存储层去查询,失去了缓 存保护后端存储的意义。
造成缓存穿透的基本原因有两个。第一,自身业务代码或者数据出现问题,第二,一些恶意攻击、爬虫等造成大量空命中。
解决缓存穿透:
-
缓存空对象:当存储层不命中后,仍然将空对象保留到缓存层 中,之后再访问这个数据将会从缓存中获取,这样就保护了后端数据源。
缓存空对象会有两个问题:
第一,空值做了缓存,意味着缓存层中存了 更多的键,需要更多的内存空间(如果是攻击,问题更严重),比较有效的 方法是针对这类数据设置一个较短的过期时间,让其自动剔除。
第二,缓存 层和存储层的数据会有一段时间窗口的不一致,可能会对业务有一定影响。 -
布隆过滤器拦截
在访问缓存层和存储层之前,将存在的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四种分布式的批量操作方式
- 串行命令:它的
操作时间=n次网络时间+n次命令时间,网络次数是n
。很显然这种方案不是最优的,但是实现起来比较简单。 - 串行IO:Redis Cluster使用CRC16算法计算出散列值,再取对16383的余数就可以算出slot值,同时10.5节我们提到过Smart客户端会保存slot和节点的对应关系,有了这两个数据就可以将属于同一个节点的key进行归档,得到每个节 点的key子列表,之后对每个节点执行mget或者Pipeline操作,它的
操作时间 =node次网络时间+n次命令时间,网络次数是node的个数
,整个过程如图11- 10所示,很明显这种方案比第一种要好很多,但是如果节点数太多,还是有 一定的性能问题。 - 并行IO:此方案是将方案2中的最后一步改为多线程执行,网络次数虽然还是节点个数,但由于
使用多线程网络时间变O(1)
,这种方案会增加编程的复杂度。 - hash_tag实现:Redis Cluster的hash_tag功能,它可以将多个key强制分配到 一个节点上,它的
操作时间=1次网络时间+n次命令时间
六、缓存雪崩
缓存雪崩:由于缓存层承载着大量请求,有效地保护了存储层,但是如果缓存层由于某些原因不能提供服务,于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会级联宕机的情况。
预防和解决缓存雪崩问题:
- 保证缓存层服务高可用性:Redis Sentinel和Redis Cluster都实现了高可用。
- 依赖隔离组件为后端限流并降级:推荐一个Java依赖隔离工具 Hystrix(https://github.com/netflix/hystrix)
- 提前演练:在项目上线前,演练缓存层宕掉后,应用以及后端的负 载情况以及可能出现的问题,在此基础上做一些预案设定。
七、热点key重建优化(缓存击穿)
开发人员使用“缓存+过期时间”的策略既可以加速数据读写,又保证数据的定期更新,这种模式基本能够满足绝大部分需求。但是有两个问题如果同时出现,可能就会对应用造成致命的危害:
- 当前key是一个热点key(例如一个热门的娱乐新闻),并发量非常大。
- 重建缓存不能在短时间完成,可能是一个复杂计算,例如复杂的 SQL、多次IO、多个依赖等。
在缓存失效的瞬间,有大量线程来重建缓存,造成后端负载加大,甚至可能会让应用崩溃。
解决方法:
- 互斥锁(mutex key):此方法只允许一个线程重建缓存,其他线程等待重建缓存的线程执行 完,重新从缓存获取数据即可。
- 永远不过期
“永远不过期”包含两层意思: 从缓存层面来看,确实没有设置过期时间,所以不会出现热点key过期 后产生的问题,也就是“物理”不过期。 从功能层面来看,为每个value设置一个逻辑过期时间,当发现超过逻 辑过期时间后,会使用单独的线程去构建缓存。
从实战看,此方法有效杜绝了热点key产生的问题,但唯一不足的就是重构缓存期间,会出现数据不一致的情况,这取决于应用方是否容忍这种不 一致。