阿里妹导读: 响应时间长, 遇到性能瓶颈时, 开发者第一个想到的总是性能优化.《什么技能产品经理不会提, 但技术人必须懂?》讲到了什么时候需要使用缓存. 但缓存的用法是什么? 一旦缓存使用不当, 或稍有不注意, 反而会翻车, 导致系统投入更多的维护成本, 陡增更高的复杂度. 今天, 科怀就来讲讲缓存的正确使用姿势.
1. 常见概念
在合理应用缓存前, 需要了解缓存领域里相关的几个常用术语:
1)缓存命中: 表示数据能够从缓存中获取, 不需要回源;
2)Cache miss: 表示没有命中缓存, 如果缓存内存中还有内存空间的话, 会将数据加入到缓存中;
3)存储成本: 当没有命中缓存时, 回源获取后会将数据放置到存储中, 整个将数据放置到存储空间所需要的时间以及空间称之为存储成本;
4)缓存失效: 当源数据发生变更后, 意味着缓存中的数据失效;
5)缓存污染: 将不经常访问的数据放置到缓存存储空间中, 以至于高频访问的数据无法放置到缓存中;
6)替代策略: 当数据放置到缓存空间时, 由于空间不足时, 就需要从缓存空间中去除已有的数据, 选择去除哪些数据就是由替代策略决定的. 常见的替代策略有如下这些:
- Least-Recently-Used(LRU)
- Least-Frequently-Used(LFU)
- SIZE
- First in First Out(FIFO)
由于存储空间有限, 替代策略要解决的核心问题是尽量保留高频访问的缓存数据, 降低缓存污染以提升缓存命中率和整体的缓存效率, 难点在于, 需要基于数据历史访问情况, 以一种合适的对未来访问情况的预估才能找到更佳的策略.
2. 访问缓存场景分析
使用缓存通常的操作是, 请求先访问缓存数据, 如果缓存中不存在的话, 就会回源到数据库中然后将数据写入到缓存中; 如果存在的话就直接返回数据. 从整个过程来看, 缓存层就处于数据访问的前置环节, 分担数据库在高并发容易出现系统故障的风险, 所以在使用过程中需要对缓存层很谨慎的进行分析. 在访问缓存数据时, 有常见的三大场景: 缓存穿透, 缓存击穿以及缓存雪崩.
2.1 缓存穿透
现象: 每次请求直接穿透缓存层, 直接回源到数据库中, 给数据库带来了巨大访问压力, 甚至宕机.
原因: 访问数据会先访问缓存, 如果数据不存在缓存中才会查询数据库, 但是如果查询数据库也查询不出来数据, 也是说当前访问数据永远不会写入缓存中. 这样就导致了, 访问一定不存在的数据, 就相当于缓存层形同虚设, 每次请求都会到 db 层, 造成数据库负担过大.
解决方案:
方案一: 采用 bloom filter 保存缓存过的 key, 在访问请求到来时可以过滤掉不存在的 key, 防止这些请求到 db 层;
方案二: 如果 db 查询不到数据, 保存空对象到缓存层, 设置较短的失效时间;
方案三: 针对业务场景对请求的参数进行有效性校验, 防止非法请求击垮 db.
2.2 缓存击穿
现象: 当某一 key 失效时, 造成大量请求到 db 层, 击垮存储层.
原因: 为了保证缓存数据的时效性, 通常会设置一个失效时间, 如果是热点 key, 高并发时会有海量请求直接越过缓存层到数据库, 这样就会给数据库造成的负担增大, 设置宕机.
解决方案
方案一: 使用互斥锁, 当缓存数据失效时, 保证一个请求能够访问到数据库, 并更新缓存, 其他线程等待并重试;
方案二: 缓存数据 "永远不过期", 如果缓存数据不设置失效时间的话, 就不会存在热点 key 过期造成了大量请求到数据库. 但是, 缓存数据就变成 "静态数据", 因此当缓存数据快要过期时, 采用异步线程的方式提前进行更新缓存数据.
2.3 缓存雪崩
现象: 多个 key 失效, 造成大量请求到 db 层, 导致 db 层负担过重甚至宕机.
原因: 缓存雪崩是指在我们设置缓存时采用了相同的过期时间, 导致缓存在某一时刻同时失效, 请求全部转发到数据库, 最终导致数据库瞬时压力过大而崩溃.
解决方案:
方案一: 使用互斥锁的方式, 保证只有单个线程进行请求能够达到 db;
方案二: 多每个 key 的失效时间在基础时间上再加上一个 1~5 分钟的随机值, 这样就能保证大规模 key 集体失效的概率, 并且需要尽量让多个 key 的失效时间能够均匀分布;
2.4 总结
缓存穿透, 缓存击穿以及缓存雪崩这三个术语很容易弄混, 也是读缓存中典型的三个场景问题, 做一下简单的总结是很有必要的. 缓存穿透强调是获取本不存在的缓存数据, 请求必然会越过缓存层直接到达到存储层, 很明显这是利用业务规则的漏洞对系统发起攻击, 解决方案的核心原则是过滤这些非法业务请求, 与是否是热点数据, 缓存失效时间等因素没有关系.
缓存击穿强调的是热点 key 的失效, 导致某一时刻大量请求会直接到 db 层, 解决方案的核心原则是规避数据库的并发操作. 缓存雪崩强调的多个 key 的集体失效, 与 key 是否是热点数据并不是必然的因素, 解决方案的核心原则则让 key 之间的失效时间分布更加均匀, 避免集体失效的情况.
3. 数据更新场景分析
引入缓存后数据会分别存放到缓存以及数据库两个地方, 因此数据更新时, 需要涉及到这两处地方得更新, 并且更新时序的不同会有不同的结果. 关于数据更新目前业界已经沉淀了 Cache Aside Pattern,Read/Write through 等多种方式.
3.1 Cache Aside Pattern
这是很通用的更新策略, 主要流程如下:
- cache.delKey(key);
- db.update(data);
- Thread.sleep(xxx);
- cache.delKey(key);
- https://www.cnblogs.com/Leo_wl/p/9062029.html?spm=ata.13261165.0.0.1fbe62a58KTCCF
- https://blog.csdn.net/zeb_perfect/article/details/54135506?spm=ata.13261165.0.0.1fbe62a58KTCCF
- https://www.cnblogs.com/Leo_wl/p/9062029.html?spm=ata.13261165.0.0.1fbe62a58KTCCF#_label0_0
- https://www.jianshu.com/p/8950c52ce53b?spm=ata.13261165.0.0.3d1462a5BuyJzs
- https://www.jianshu.com/p/22c7e9ab5d15?spm=ata.13261165.0.0.3d1462a5BuyJzs
- https://www.cnblogs.com/rjzheng/p/9041659.html?spm=ata.13261165.0.0.3d1462a5BuyJzs
- https://www.jianshu.com/p/8950c52ce53b?spm=ata.13261165.0.0.3d1462a5BuyJzs
- https://blog.kido.site/2018/11/24/db-and-cache-preface/?spm=ata.13261165.0.0.3d1462a5BuyJzs
- https://msd.misuland.com/pd/3255817997595443436?spm=ata.13261165.0.0.3d1462a5BuyJzs
- https://blog.51cto.com/14214194/2411931?spm=ata.13261165.0.0.3d1462a5BuyJzs
- https://www.cnblogs.com/pomer-huang/p/8998623.html?spm=ata.13261165.0.0.3d1462a5BuyJzs
- https://blog.csdn.net/zjttlance/article/details/80234341?spm=ata.13261165.0.0.3d1462a5BuyJzs
- https://stor.51cto.com/art/201908/600603.htm?spm=ata.13261165.0.0.3d1462a5BuyJzs
- https://yq.aliyun.com/articles/652472?spm=ata.13261165.0.0.3d1462a5BuyJzs&utm_content=m_1000018600
- https://blog.csdn.net/ruanchengmin/article/details/79210632?spm=ata.13261165.0.0.3d1462a5BuyJzs
来源: https://yq.aliyun.com/articles/738400