一、多级缓存架构

1.缓存和缓冲

cache，速度相差较大的两种硬件之间，用于协调二者数据传输速度差异的结构。

CPU l1/l2/l3 cache; innodb buffer pool ;redis ;memcached

buffer,临时存储区域，保存从一个区域传输到另一个设备的数据。

java io; write cache ;消息队列缓存写请求

缓存技术本质：以空间换时间

2. 3W1H

内容；有效期；缓存方案（APP 缓存/HTTP 缓存/CDN/Nginx/memcached/redis...）；更新机制(过期更新/定期更新/主动更新)；

3. 多级缓存架构

4.缓存技术概要

APP 缓存：将数据缓存到本地，本地文件/本地图片/SQLITE 缓存

HTTP 缓存：标准协议缓存，HTTP 资源

CDN 缓存：内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获得所需内容，降低网络堵塞，提高用户访问响应速度和命中率。关键是内容存储和分发。

WEB 缓存：静态资源，图片,JS，css 等。配置 http 协议实现缓存。

应用缓存：应用在本地的缓存数据，进程内缓存 oscache ehcache,进程外缓存，本地磁盘 SSD 缓存

分布式缓存：由分布式系统提供缓存，redis memcached

5.redis 和 memcached

如果由较大的缓存对象读写就用 memcached，否做 redis

如果数据库+缓存，用 memcached 更简单；

如果缓存生成代价高，用 redis。

二、分布式缓存架构设计

1.分布式缓存 2 种行式

数据缓存：用什么缓存系统；如何应对数据一致性挑战。实时性要求高的场景，读多写少，微博浏览。

结果缓存：用什么缓存；缓存有效期与结果新鲜度平衡，计算量大但实时性要求不高的场景，热榜排行榜。

2.缓存设计思路

3.缓存数据一致性设计

容忍一致性；关系数据库本地表事务；消息队列异步删除

4.缓存架构三类问题

a.缓存穿透：缓存没有发挥做用，业务系统虽然缓存了查询数据，但缓存中没有数据，业务系统需要再次去系统查询数据。

空值缓存：读不到写入空值；缓存当前数据：分为历史数据和当前数据，只存当前数据

缓存预热：回复发布/预发布；随机失效：一个时间范围内的随机值，失效。

b.缓存雪崩：当缓存失效后，引起系统性能急剧下降的情况。系统存储无法支撑读写请求等；

解决方案：更新锁；后台更新

c.缓存热点：特别热点的数据，如有业务都请求同一份缓存，缓存服务器压力过大。解决方法：多副本缓存

三、负载均衡架构

1.多级负载均衡架构

性能需求和维护复杂度

2.技术分析

DNS:地理位置和机房级别的负载均衡，标准协议；能力有限不够灵活；DNS 劫持；DNS 缓存

HTTP-DNS：APP 客户端；

3.GSLB

全局负载均衡主要用于在多个地区拥有自己的服务器的站点，为全球用户以一个 IP 地址或域名就能访问到离自己最近的服务器，从而获得最快的访问速度。

适合超大规模业务，多地甚至全球业务部署。

功能强大，可实现就近访问，容灾切换、流量调节。

4.F5

性能高（700 万请求），价格贵（100 万 RMB）

5.LVS

内核级别的负载均衡，基本可以跑满千兆网卡带宽，性能 10~100 万请求。

6.F5/LVS/Nginx 三者对比

四、负载均衡技巧

1.通用负载均衡算法

a.轮询和随机

将请求依次发给服务器；将请求随机发给服务器

适用于无状态的负载均衡；缺点当一个点发送故障，负载系统无感知，依然会向故障点发送请求。

b.加权

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

适用于服务器能力有差异的场景；配置不合理，可能导致过载；

c.加权轮询算法

d.负载优先

负载均衡系统将任务分配给当前负载最低的服务器，这里的负载根据不同的额任务类型和业务场景，可以用不同的指标进行衡量。

LVS 为 4 层网络负载均衡设备；Nginx 为 7 层网络负载均衡系统。

e.性能优先

将任务分配给性能最好的服务器，主要以响应时间作为性能横量指标。

f.hash

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

2.nginx--常用负载均衡算法

3.LVS--常用负载均衡算法

4. 业务级别负载均衡技巧

a.通用负载均衡算法基于请求，业务级别负载均衡算法基于业务内容，更灵活；

b.cookie 负载均衡信息

应用 session 保持，购物车下单等场景

5.自定义 http Header

6.query string:含负载均衡信息，但业务入侵大

7.服务器性能估算

接口性能：线上业务服务器接口处理时间分布 20~100ms;平均大概 50ms

服务器性能：线上单个服务器性能大概为 300~1000TPS/QPS

服务器数量=（总 TPS+QPS）/单个服务器性能

五、接口高可用

1.接口高可用整体框架

请求过多：限流/排队----防止雪崩

接口故障多：熔断/降级----防止链式效应

2.限流

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

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

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

3.固定 &滑动时间窗口

固定窗口：统计固定时间周期内的请求量，超过阈值就限流

滑动时间窗：统计的滑动时间内的请求量，超过阈值限流

4.漏桶

请求放入“桶”，例如消息队列，业务处理单元（线程/进程/服务）从桶里拿请求处理，通满了就丢弃新的请求。可用于瞬时高并发，例如 0 点签到，秒杀

5.令牌桶

某个处理单元按照速率将令牌放入桶中，业务处理单元收到请求后，需要获取令牌，获取不到就丢弃请求。

6.排队

收到请求后，不同步处理，将请求放入队列，系统根据能力进行异步处理。

请求缓存+同步改异步+请求端轮询

常用：秒杀/抢购

7.排队示例

降级

建立独立操作系统，可以是独立降级系统，也可以是嵌入到其他系统的降级功能。降级核心业务。

9.熔断

下游接口故障时，一定时间内不再调用。框架或者 SDK 实现