分布式缓存架构模式1 - 数据缓存

【设计核心】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)

缓存雪崩

【定义】

当缓存失效（过期）后引起系统性能急剧下降的情况

缓存雪崩 - 技术本质

缓存雪崩的根因：1. 生成缓存较慢（复杂的数据查询、大量的计算等）；2. 缓存失效后并发请求量较大，例如50个以上。

缓存雪崩应对方法

1：更新锁

【方案】

1. 对缓存更新操作进行加锁保护，保证只有一个线程能够进行缓存更新；

2. 未能获取更新锁的线程要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。

【优缺点】

1. 需要引入分布式锁；2. 能够保证只有一个线程能更新。

2：后台更新

【方案】

1. 由后台线程来更新缓存，而不是由业务线程来更新缓存；

2. 缓存有效期设置为永久，后台线程更新缓存，更新策略分为“定时更新”、“事件触发更新”；

3. 业务线程只读取缓存，缓存不存在就返回空值。

【优缺点】

1. 实现简单；2. 需要保证后台线程高可用。

缓存热点

【定义】

特别热点的数据，如果大部分甚至所有的业务请求都命中同一份缓存数据，则这份数据所在的缓存服务器的压力也很大，有可能撑不住。

【场景】

热点事件、突发事件

例如，某明星微博发布“我们”来宣告恋爱了，短时间内上千万的用户都会来围观。

缓存热点应对方法

【方案细节】

1.写入的时候，缓存的Key加上编号，写入到多个缓存服务器；

2.读取的时候随机生成编号组装Key，然后读取。

【挑战】

不太好预料哪些Key是热点（微博系统经常挂的原因），需要动态决策或者人工干预。