【设计核心】1. 用什么缓存系统；2. 如何应对数据一致性挑战。
【应用场景】实时性要求高的业务，读多写少的场景，例如：微博浏览。
分布式缓存架构模式2 – 结果缓存
【设计核心】1. 用什么缓存系统；2. 缓存有效期与结果新鲜度的平衡。
【应用场景】计算量大但实时性要求不高的业务场景，例如推荐、热榜、排行榜、分页。
分布式缓存架构设计思路
数据缓存架构的一致性复杂度
【读操作】
1. 读缓存系统；
2. 读不到再去读存储系统。
【写操作】
1. 先写缓存后写存储
写缓存成功写存储失败，单个数据在缓存有效期内读取没问题，但是关联业务会出异常，例如订单数据，用户自己能看到订单，但是系统统计不到这个订单。
2. 先写存储后写缓存
写存储成功写缓存失败，业务读到的是旧数据，缓存失效后才能更新为新数据。
3. 先删除缓存再写存储系统
正常情况下能保证数据一致性，但是缓存系统异常的时候，为了不影响写入存储系统，还是需要
继续写入，同样会导致不一致。
4. 双删（适合全局数据，例如运营活动图片）
先删除缓存，再写存储，再删除缓存。
数据缓存架构的一致性解决方案
1：容忍不一致性
【方案】
根据容忍度设定缓存的有效期，例如新闻资讯、微博、商品信息等。
【优缺点】
1. 简单；
2. 一定时期的数据不一致。
2：关系数据库本地表事务
【方案】
1. 正常的时候采用先删除缓存后写入数据库的策略；
2. 缓存系统异常的时候，通过事务记录一条消息到本地消息表，然后后台定时读取消息表记录，重试删除操作。
【优缺点】
1. 复杂；
2. 数据不一致时间短，等于重试间隔。
3：消息队列异步删除
【方案】
1. 正常的时候采用先删除缓存后写入数据库的策略；
2. 缓存系统异常的时候，发送一条删除操作给消息队列，然后后台读取消息队列记录，重试删除操作。
【优缺点】
1. 复杂；
2. 数据不一致时间短，等于重试间隔；
3. 消息队列可能挂掉。
缓存架构三类问题
缓存穿透
【定义】
缓存没有发挥作用，业务系统虽然去缓存查询数据，但缓存中没有数据，业务系统需要再次去存储系统查询数据。
【场景】
1. 存储系统中确实不存在被访问的数据
例如被黑客攻击，导致大量无效业务请求。
2. 存储中存在，但缓存中不存在的数据
例如冷门数据、老数据，常见的一个场景是爬虫或者用户翻页翻到20页以后导致系统变慢。
3. 系统刚启动的时候，大量缓存还没有生成
例如抢购、秒杀等，或者缓存节点刚启动。
4. 缓存集中失效
例如批量生成的缓存批量失效，缓存服务器挂掉。
缓存雪崩 – 技术本质
缓存雪崩的根因：1. 生成缓存较慢（复杂的数据查询、大量的计算等）；2. 缓存失效后并发请求量较大，例如50个以上。
缓存热点
【定义】
特别热点的数据，如果大部分甚至所有的业务请求都命中同一份缓存数据，则这份数据所在的缓存服务器的压力也很大，有可能撑不住。
【场景】
热点事件、突发事件
例如，某明星微博发布“我们”来宣告恋爱了，短时间内上千万的用户都会来围观。
缓存热点应对方法
【方案细节】
1. 写入的时候，缓存的 Key 加上编号，写入到多个缓存服务器；
2. 读取的时候随机生成编号组装 Key，然后读取。
【挑战】
不太好预料哪些 Key 是热点（微博系统经常挂的原因） ，需要动态决策或者人工干预。
原文始发于微信公众号（二进制跳动）：计算架构模式之分布式缓存架构设计
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/167128.html
