多级缓存架构

缓存原理和设计框架

缓存 【定义】

英文单词是 Cache ，指位于速度相差较大的

两种硬件之间，用于协调两者数据传输速度差

异的结构，均可称之为 Cache。

【常见 Cache】

1. CPU L1/L2/L3 cache；

2. Linux 文件系统 page cache；

3. Innodb buffer pool；

4. Redis、Memcached。

缓冲【定义】

英文单词是 Buffer ，指某个临时存储区域，保

存将要从一个设备（或者系统）传输到另一个

设备（或系统）的数据。

【常见 Buffer】

1. Java IO BufferdInputStream 等；

2. 磁盘控制器写缓存（Write cache）；

3. MySQL log buffer；

4. 消息队列缓冲写请求；

5. Innodb buffer pool。

缓存的技术本质

凡是位于速度相差较大的两种硬件之间，用于协调两者数据传输速度差异的结构，均可称之为 Cache。

-- Wikipedia

凡是位于性能相差较大的两种系统之间，用于协调两者性能差异的结构，均可称之为 Cache。

-- 架构实战营

缓存技术本质：空间换时间，例如 CPU Cache、磁盘 Cache、OS 文件系统 Cache。

缓存设计框架 - - 3W1H

缓存设计框架 - - 更新机制

多级缓存架构

5 级缓存架构

多级缓存架构设计关键点

问题 1 应用多级缓存架构的时候，如果数据发生变化了，如何保证每一级及时更新数据？

问题 2 多级缓存大大增加了架构复杂度，直接用分布式缓存不是更简单么？

问题 3 是否所有业务都要按照这个多级缓存架构来做？

1. 性能需求；2. 架构复杂度。

4 级缓存架构

3 级缓存架构

缓存技术概要介绍

本地缓存

App【定义】

App 将数据缓存在本地。

【应用场景】

所有能缓存的都可以缓存。

【常见技术】

1. SQLite 缓存；

2. 本地文件缓存；

3. 图片缓存：Picasso(Square)、

Fresco(Facebook)、Glide(Google)。

HTTP【定义】

HTTP 标准协议缓存。

【应用场景】

HTTP 资源。

【具体实现】

1. 参考 HTTP 协议、Cache-Control、

ETag/If-None-Match 等指令。

CDN 缓存

【定义】

Content Delivery Network，即内容分发网络，依靠部署

在各地的边缘服务器，通过中心平台的负载均衡、内容分

发、调度等功能模块，使用户就近获取所需内容，降低网

络拥塞，提高用户访问响应速度和命中率，关键技术是内

容存储和分发技术。

【优缺点】

1. 功能强大，能够支撑超高流量；

2. 贵。

【典型场景】

1. 直播（RTMP、HLS）；

2. 视频；

3. 资讯。

【国内供应商】

阿里云、网宿、腾讯云、金山云、七牛云……

Web 容器缓存

Web 容器一般缓存静态资源，例如图片、JavaScript、CSS 等，配合 HTTP 协议实现缓存。

应用缓存 + + 分布式缓存

应用缓存【定义】

应用在本地缓存数据。

【应用场景】

所有能缓存的都可以缓存。

【常见技术】

1. 进程内缓存、ConcurrentHashMap、

OSCache、Ehcache 等；

2. 进程外缓存，堆外内存；

3. 本地磁盘 SSD 缓存。

分布式缓存【定义】

由分布式系统提供缓存功能。

【应用场景】

所有能缓存的都可以缓存。

【具体实现】

1. Redis；

2. Memcached。

思维导图

分布式缓存架构设计

分布式缓存架构两种模式

数据缓存

【设计核心】 1. 用什么缓存系统；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. 缓存集中失效

例如批量生成的缓存批量失效，缓存服务器挂掉。

缓存雪崩：缓存失效引起雪崩效应

【定义】

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

缓存热点：部分缓存访问量超高

【定义】

特别热点的数据，如果大部分甚至所有的业务请求都命中同一份缓存数据，则这份数据所在的缓

存服务器的压力也很大，有可能撑不住。

【场景】

热点事件、突发事件

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

思维导图

负载均衡架构

负载均衡整体架构

4 级负载均衡

多级负载均衡架构设计关键点

问题 1 多级级联加长了处理路径，性能应该会受到影响，为何还要这么设计？

问题 2

多级级联架构很复杂，看起来违背了架构的简单原则，直接用 F5 或者 LVS 负载均衡到服

务网关不就可以了么？

问题 3 是否所有业务都要按照这个多级级联来设计负载均衡架构？

设计关键 1. 性能需求；2. 维护复杂度。

3 级负载均衡架构

2 级负载均衡架构变化

负载均衡技术剖析

DNS、HTTP - - DNS、GSLB、F5、LVS

思维导图

负载均衡技巧

通用负载均衡算法

轮询 & & 随机

【基本原理】

轮询：将请求依次发给服务器。

随机：将请求随机发给服务器。

【适应场景】

通用，无状态的负载均衡。

【优缺点】

1. 实现简单；

2. 不会判断服务器状态，除非服务器连接丢失。

【问题场景】

1. 某个服务器当前因为触发了程序 Bug 进入了死循环导致 CPU 负载很高，负载

均衡系统是不感知的，还是会继续将请求源源不断地发送给它。

2. 集群中有新的机器是 32 核的，老的机器是 16 核的，负载均衡系统也是不关注

的，新老机器分配的任务数是一样的。

加权轮询

【基本原理】

按照预先配置的权重，将请求按照权重比例发送给不同的服务器。

【适应场景】

服务器的处理能力有差异，例如新老服务器搭配使用。

【优缺点】

1. 实现复杂，按照权重计算；

2. 不会判断服务器状态，除非服务器连接丢失；

3. 权重配置不合理可能导致过载。

【问题场景】

2020 年采购的机器 CPU 核数是 2019 年采购的机器 1 倍，运维直接配置了 2 倍权重，

结果导致新机器全部过载。

负载优先

【基本原理】

负载均衡系统将任务分配给当前负载最低的服务器，这里的负载根据不同的任务

类型和业务场景，可以用不同的指标来衡量。

【适应场景】

1. LVS 这种 4 层网络负载均衡设备，可以以“连接数”来判断服务器的状态，服

务器连接数越大，表明服务器压力越大。

2. Nginx 这种 7 层网络负载系统，可以以“HTTP 请求数” 来判断服务器状态

（Nginx 内置的负载均衡算法不支持这种方式，需要进行扩展）。

【优缺点】

1. 实现复杂，需要管理或者获取服务器状态

2. 可以根据服务器状态进行负载均衡

性能优先

【基本原理】

负载均衡系统将任务分配给当前性能最好的服务器，主要是以响应时间作为性能

衡量标准。

【适应场景】

Nginx 这种 7 层网络负载系统，可以以“HTTP 响应时间” 来判断服务器状态

（Nginx 内置的负载均衡算法不支持这种方式，需要进行扩展）。

【优缺点】

1. 实现复杂，需要统计请求处理时间，需要耗费一定的 CPU 运算资源

2. 可以根据性能进行负载均衡

3. 如果服务器响应不经过负载均衡器，则不能应用这种算法

Hash

【基本原理】

基于某个参数计算 Hash 值，将其映射到具体的服务器。

【适应场景】

1. 有状态的任务，例如购物车；

2. 任务是分片的，例如某个用户的请求只能在某台服务器处理。

【优缺点】

1. 实现简单；

2. 不会判断服务器状态，除非服务器连接丢失。

【常见 Hash 键】

1. 用户 IP 地址（session 场景）

2. URL（缓存场景）

常见业务负载均衡技巧

Cookie、自定义 HTTP Header、 HTTP y query string

思维导图

接口高可用

接口高可用整体框架

雪崩效应：请求量超过系统处理能力后导致系统性能螺旋快速下降。

链式效应：某个故障引起后续一连串的故障。

限流

用户请求全流程各个环节都可以限流：

1. 请求端限流：发起请求的时候就进行限流，被限流的请求实际上并没有发给后端服务器。

2. 接入端限流：接到业务请求的时候进行限流，避免业务请求进入实际的业务处理流程。

3. 微服务限流：单个服务的自我保护措施，处理能力不够的时候丢弃新的请求。

限流方式

请求端限流

接入端限流

微服务限流

排队

基本原理：收到请求后并不同步处理，而是将请求放入队列，系统根据能力异步处理。

技术本质：请求缓存 + 同步改异步 + 请求端轮询。

应用场景：秒杀、抢购

降级

基本原理：直接停用某个接口或者 URL，收到请求后直接返回错误（例如 HTTP 503）。

应用场景：故障应急，通常将非核心业务降级，保住核心业务，例如降级日志服务、升级服务等。

熔断

基本原理：下游接口故障的时候，一定时期内不再调用。

应用场景：服务自我保护，防止故障链式效应。

思维导图