架构04-透明多级分流系统

零、文章目录

架构04-透明多级分流系统

1、透明多级分流系统

(1)概述
  • **定义:**透明多级分流系统是指在用户请求从客户端发出到最终查询或修改数据库信息的过程中,通过多个技术部件对流量进行合理分配,以提高系统的性能和可靠性。
  • 设计原则:
    • **减少单点部件:**尽量减少系统中的单点部件,如果不可避免,应减少到达这些部件的流量。
    • **奥卡姆剃刀原则:**如无必要,勿增实体。系统设计应尽量简洁,避免不必要的复杂性。
(2)系统部件的价值
  • **边缘部件:**如本地缓存、内容分发网络(CDN)、反向代理等,能够迅速响应用户请求,减轻后方I/O和CPU的压力。
  • **可扩展部件:**如集群中的服务节点,可以通过增加机器来提高并发性能,适合承载主要业务逻辑。
  • **核心部件:**如服务注册中心、配置中心,对系统运行有全局性影响,需保持高可用性和容错备份。
  • **单点部件:**如系统入口的路由、网关、负载均衡器和传统关系数据库,只能通过升级硬件来提升性能,容易成为瓶颈。
(3)DNS域名解析系统
  • DNS系统是一个典型的透明多级分流系统
  • **作用:**将人类易读的域名转换为计算机处理的IP地址。
  • 递归解析过程:
    1. **本地缓存检查:**客户端先检查本地DNS缓存,查看是否存在该域名的地址记录。
    2. **本地DNS查询:**如果缓存中没有记录,客户端将请求发送给本地DNS服务器。
    3. **权威服务器查询:**本地DNS服务器依次查询是否有该域名的权威服务器记录,直至查询到根域名服务器。
    4. **递归查询:**从根域名服务器开始,逐步查询到具体的权威服务器。
    5. **获取地址记录:**通过权威服务器获取域名的地址记录,可能包括A记录、AAAA记录、CNAME记录等。
  • DNS系统的优势与挑战
    • 优势:
      • **多级分流:**通过多级查询和缓存机制,能够处理全球网络流量。
      • **智能路由:**根据访问者的地理位置和服务商等因素,返回最合适的IP地址。
    • 挑战:
      • **响应速度:**在极端情况下,递归查询可能导致较高的延迟。
      • **中间人攻击:**每一级查询都可能受到劫持,特别是本地运营商的DNS服务器。
  • 前端优化手段帮助应对这些挑战
    • **DNS预取(DNS Prefetching):**在网页加载时提前解析后续可能使用的域名,减少延迟。
    • **DNS over HTTPS(DoH):**通过HTTPS协议进行DNS解析,绕过传统Local DNS,提高安全性和可靠性。

2、HTTP协议的客户端缓存机制

(1)引言
  • **无状态交互原则:**HTTP协议设计之初,确定了服务端与客户端之间的"无状态"交互原则,即每次请求都是独立的,不依赖前一次请求的状态。
  • **问题:**无状态交互虽然简化了服务器设计,但也导致了重复数据传输,降低了网络性能。
  • **解决方案:**客户端缓存机制。
(2)客户端缓存分类
  • **状态缓存:**不经过服务器,客户端直接根据缓存信息判断目标网站的状态。
    • 示例:301/Moved Permanently、HSTS(HTTP Strict Transport Security)。
  • **强制缓存:**客户端根据缓存信息直接使用资源,无需再次请求服务器。
  • **协商缓存:**客户端与服务器协商资源是否已更改,决定是否使用缓存。
(3)强制缓存
  • Expires Header
    • **定义:**HTTP/1.0 协议中引入,跟随一个截止时间参数。
    • 示例:
http 复制代码
HTTP/1.1 200 OK
Expires: Wed, 8 Apr 2020 07:28:00 GMT
复制代码
- **问题:**
    * 客户端时间调整可能导致缓存提前失效或超期持有。
    * 无法强制浏览器不允许缓存某个资源。
  • Cache-Control Header
    • **定义:**HTTP/1.1 协议中引入,语义更丰富。
    • **优先级:**如果 Cache-Control 和 Expires 同时存在且语义冲突,以 Cache-Control 为准。
    • 参数:
      • **max-age:**以秒为单位,表示缓存的有效时间。
      • **s-maxage:**共享缓存的有效时间,主要用于 CDN。
      • **public/private:**资源是否可以被代理、CDN 缓存。
      • **no-cache:**资源不应被缓存,但协商缓存仍生效。
      • **no-store:**禁止任何形式的缓存。
      • **no-transform:**禁止资源被修改。
      • **min-fresh:**建议服务器返回不少于该时间的缓存资源。
      • **only-if-cached:**只使用缓存,缓存未命中则返回 503/Service Unavailable。
      • **must-revalidate:**资源过期后必须从服务器获取。
      • **proxy-revalidate:**提示代理、CDN 资源过期后的缓存行为。
(4)协商缓存
  • 基于资源修改时间
    • **Last-Modified:**服务器响应 Header,表示资源的最后修改时间。
    • **If-Modified-Since:**客户端请求 Header,发送上次收到的资源最后修改时间。
    • 示例:
      • 未修改:
http 复制代码
HTTP/1.1 304 Not Modified 
Cache-Control: public, max-age=600
Last-Modified: Wed, 8 Apr 2020 15:31:30 GMT
复制代码
    * **已修改:**
http 复制代码
HTTP/1.1 200 OK 
Cache-Control: public, max-age=600
Last-Modified: Wed, 8 Apr 2020 15:31:30 GMT
Content
  • 基于资源唯一标识
    • **ETag:**服务器响应 Header,表示资源的唯一标识。
    • **If-None-Match:**客户端请求 Header,发送上次收到的资源唯一标识。
    • 示例:
      • 未修改:
http 复制代码
HTTP/1.1 304 Not Modified
Cache-Control: public, max-age=600
ETag: "28c3f612-ceb0-4ddc-ae35-791ca840c5fa"
复制代码
    * **已修改:**
http 复制代码
HTTP/1.1 200 OK
Cache-Control: public, max-age=600 
ETag: "28c3f612-ceb0-4ddc-ae35-791ca840c5fa"
Content
(5)内容协商机制
  • **定义:针对一个 URL 提供多个版本的资源,通过 Accept 和 Content- Headers 实现。
  • **Vary Header:**指示缓存应根据哪些请求 Header 来缓存资源。
    • 示例:
http 复制代码
HTTP/1.1 200 OK
Vary: Accept, User-Agent

3、传输链路

(1)传输链路的重要性
  • **定义:**传输链路是指程序发出的请求从客户端到服务器的过程。
  • **影响因素:**网络路由跳点数量、运营商铺设线路质量等。
  • **开发者控制:**虽然传输链路看似不可控,但程序请求与应用层、传输层协议的匹配度对传输效率有很大影响。
(2)前端优化技巧
  • 减少请求数量
    • **方法:**CSS、JS 文件合并/内联,合并 Ajax 请求。
    • **目的:**减少建立通信链路的开销,提高访问性能。
  • 扩大并发请求数
    • **方法:**域名分片(Domain Sharding)。
    • **目的:**利用浏览器对每个域名支持的并发请求数限制,加快资源加载速度。
  • 启用压缩传输
    • **方法:**启用 GZip 压缩。
    • **目的:**减少传输内容的大小,节省网络流量。
  • 避免页面重定向
    • **目的:**减少文档传输的延迟,提高用户体验。
  • 按重要性调节资源优先级
    • **方法:**将重要资源放在 HTML 的头部。
    • **目的:**优先下载对客户端展示影响大的资源。
(3)HTTP 协议的发展
  • HTTP/1.0 和 HTTP/1.1
    • **特点:**基于 TCP 协议,适合长时间、大数据传输。
    • **问题:**短而小的 TCP 连接导致网络性能瓶颈。
  • HTTP/2
    • **多路复用技术:**允许多个请求和响应在同一 TCP 连接中同时传输。
    • **头压缩:**减少头部信息的传输开销。
    • **优势:**减轻服务器连接压力,提高传输效率。
  • HTTP/3
    • **基础:**基于 UDP 协议的 QUIC。
    • **特点:**独立控制每个流,提高易出错链路的性能,支持移动设备网络切换。
    • **优势:**减少网络切换延迟,提高传输可靠性。
(4)连接复用技术
  • 持久连接(Persistent Connection)
    • **原理:**客户端对同一个域名长期持有一个或多个不会用完即断的 TCP 连接。
    • **优势:**减少连接建立的开销。
    • **问题:**队首阻塞(Head-of-Line Blocking)。
  • HTTP 管道(HTTP Pipelining)
    • **原理:**客户端一次性将所有请求发送给服务端,服务端按顺序返回。
    • **问题:**难以完全避免队首阻塞。
(5)压缩技术
  • GZip 压缩
    • **原理:**压缩文本数据,减少传输量。
    • **问题:**与持久连接机制存在冲突,无法提前确定 Content-Length
  • 分块传输编码(Chunked Transfer Encoding)
    • **原理:**将响应报文分成多个分块传输,每个分块包含长度值和数据内容。
    • **优势:**解决即时压缩与持久连接的冲突问题。
(6)QUIC 协议
  • **背景:**由 Google 提出,旨在替代 TCP 协议。
  • **特点:**基于 UDP 协议,实现可靠传输,独立控制每个流。
  • **优势:**提高易出错链路的性能,支持移动设备网络切换。
  • **挑战:**互联网基础设施对 UDP 的支持有限,迁移难度大。
(7)未来展望
  • **现状:**HTTP/2 和 HTTP/3 的使用比例逐渐增加。
  • **趋势:**新旧协议交替,设备和程序将进行重大更新。

4、内容分发网络

(1)CDN 的基本概念
  • **定义:**内容分发网络(CDN)是一种古老的网络技术,通过在全球范围内分布的节点来分发内容,提高内容的加载速度和可用性。
  • **作用:**解决网络传输中的带宽、时延等问题,提高用户体验。
(2)互联网系统的速度影响因素
  • **网站服务器带宽:**服务器接入网络运营商的链路所能提供的出口带宽。
  • **用户客户端带宽:**用户接入网络运营商的链路所能提供的入口带宽。
  • **运营商互联节点带宽:**不同运营商之间互联节点的带宽。
  • **物理链路传输时延:**从网站到用户之间的物理链路传输时延。
(3)CDN 的工作过程
  • 路由解析:
    • **无CDN的解析过程:**用户请求 → 本地DNS → 递归查询 → 权威DNS → 解析结果返回浏览器。
    • **有CDN的解析过程:**用户请求 → 本地DNS → CNAME记录 → CDN权威DNS → 最优CDN节点IP → 解析结果返回浏览器。
  • 内容分发:
    • **主动分发(Push):**源站主动将内容推送到CDN节点。
    • **被动回源(Pull):**用户请求触发CDN节点从源站获取内容。
  • 资源管理:
    • **超时被动失效:**缓存资源超过生存期后重新回源。
    • **手工主动失效:**通过API接口手动刷新缓存。
(4)CDN 的应用
  • **加速静态资源分发:**CDN的核心功能,提高静态资源的加载速度。
  • **安全防御:**防御DDoS攻击等,保护源站安全。
  • **协议升级:**实现HTTP/1.x到HTTP/2或HTTP/3的协议升级。
  • **状态缓存:**缓存301/302转向等状态,减少源站压力。
  • **资源修改:**自动压缩资源、修改Header等,优化用户体验。
  • **访问控制:**实现IP黑白名单、QoS控制、防盗链等。
  • **功能注入:**在不修改源站代码的前提下,注入第三方应用。
(5)CDN 的透明性和多级分流
  • **透明性:**CDN的工作过程对用户和源站透明,无需额外配合。
  • **多级分流:**通过分布式节点实现多级分流,提高系统健壮性和应对大流量的能力。

5、负载均衡

(1)负载均衡的背景与重要性
  • **早期互联网:**单台服务器足以应对较小的流量和简单的业务。
  • **现代系统:**集群部署成为常态,无论是单体架构的多副本还是微服务架构,都需要负载均衡来扩展服务能力,确保高可用性和高性能。
  • **用户透明性:**用户只需记住一个域名,背后的复杂调度由负载均衡器处理。
(2)负载均衡的层级
  • **DNS 层面的负载均衡:**通过域名解析将用户分配到合适的数据中心。
  • **数据中心内部的负载均衡:**多级负载均衡,包括四层和七层负载均衡。
(3)四层负载均衡
  • **性能高:**直接转发数据包,效率高。
  • 常见模式:
    • **数据链路层负载均衡:**修改 MAC 地址,适用于同一子网内的负载均衡。
    • 网络层负载均衡:
      • **IP 隧道:**封装数据包,可以跨子网,但需要拆包。
      • **NAT 模式:**修改目标 IP 地址,响应需经过负载均衡器,适用于不同子网。
      • **SNAT 模式:**同时修改源和目标 IP 地址,完全透明,但真实服务器无法获取客户端 IP。
(4)七层负载均衡
  • **功能强:**工作在应用层,可以感知应用层协议,实现更复杂的路由和安全功能。
  • 常见功能:
    • **静态资源缓存:**减少后端服务器的负载。
    • **智能路由:**根据 Session、URL、用户身份等进行路由。
    • **安全防护:**抵御 DDoS 攻击、SQL 注入等。
    • **链路治理:**服务降级、熔断、异常注入等。
(5)负载均衡策略
  • **轮循均衡:**按顺序分配请求。
  • **权重轮循均衡:**根据服务器性能分配请求。
  • **随机均衡:**随机分配请求。
  • **一致性哈希均衡:**根据特征值分配请求,保证一致性。
  • **响应时间均衡:**根据服务器响应时间分配请求。
  • **最少连接数均衡:**根据当前连接数分配请求,适合长时间处理的请求。
(6)负载均衡器的实现
  • 软件均衡器:
    • **内核级:**如 LVS,性能更高。
    • **应用级:**如 Nginx、HAProxy,使用方便,功能丰富。
  • **硬件均衡器:**如 F5、A10,使用 ASIC 芯片,性能最高。
(7)多级混合负载均衡
  • **必要性:**单一层次的负载均衡难以应对复杂场景,多级混合可以更好地分配流量和资源。
  • **层次顺序:**低层在前,高层在后,因为低层负载均衡器处理速度快,高层负载均衡器功能强大,适合处理复杂应用逻辑。

6、服务端缓存

(1)引入缓存的目的
  • **缓解 CPU 压力:**通过存储方法运行结果、提前计算内容、复用公用数据等方式节省 CPU 算力,提升响应性能。
  • **缓解 I/O 压力:**通过将对较慢介质(如网络、磁盘)的读写访问转变为对较快介质(如内存)的访问,减轻 I/O 负载,提升响应性能。
(2)引入缓存的风险
  • **增加系统复杂度:**需要处理缓存的失效、更新、一致性等问题。
  • **掩盖缺陷:**问题可能在更久的时间后出现在更远的位置。
  • **安全风险:**缓存可能泄漏保密数据,成为攻击的薄弱点。
(3)缓存的属性
  • **吞吐量:**缓存的并发读写操作效率,用 OPS(每秒操作数)衡量。
  • **命中率:**成功从缓存中返回结果次数与总请求次数的比值,反映引入缓存的价值。
  • **扩展功能:**缓存提供的额外管理功能,如最大容量、失效时间、失效事件、命中率统计等。
  • **分布式支持:**缓存可以分为"进程内缓存"和"分布式缓存",前者速度快但不共享,后者支持跨节点共享。
(4)缓存的吞吐量
  • 并发场景下的吞吐量
    • **线程安全:**HashMap 不是线程安全的,需要使用 Collections.synchronizedMapConcurrentHashMap
    • **性能对比:**不同缓存组件库(如 Caffeine、Guava Cache、Ehcache 等)在并发读写场景下的性能差异显著。
  • 提高吞吐量的方法
    • **避免数据竞争:**设计数据结构以减少数据竞争,如 Caffeine 使用环形缓冲区和异步日志提交机制。
    • **异步日志提交:**将数据读写操作视为日志提交,减少锁竞争,提高吞吐量。
(5)缓存的命中率与淘汰策略
  • 基本淘汰策略
    • **FIFO(先进先出):**优先淘汰最早进入缓存的数据,命中率较低。
    • **LRU(最近最少使用):**优先淘汰最久未被使用访问的数据,适合处理热点数据。
    • **LFU(最不经常使用):**优先淘汰最不经常使用的数据,维护开销较高。
  • 改进的淘汰策略
    • **TinyLFU:**使用 Sketch 结构和滑动时间窗算法,减少计数器维护频率,处理随时间变化的热度变化。
    • **W-TinyLFU:**结合 LRU 和 LFU 的优点,通过 Window Cache 和 Main Cache 实现分段管理。
    • **ARC(自适应替换缓存):**动态调整缓存策略,提高命中率。
    • **LIRS(低最近引用集):**基于引用频率和时间间隔的缓存策略。
(6)缓存的扩展功能
  • 基本功能
    • **CacheLoader:**允许缓存主动加载指定 Key 值的数据,实现自动刷新。
    • **淘汰策略选择:**支持用户选择不同的淘汰策略。
    • **失效策略:**数据在一定时间后自动失效或刷新。
  • 高级功能
    • **事件监听器:**在数据状态变动时进行额外操作。
    • **监视能力:**提供缓存数据的监视功能。
    • **并发级别设置:**分段加锁实现并发控制。
    • **容量设置:**指定初始容量和最大容量,减少扩容频率,控制缓存大小。
    • **引用方式设置:**与 Java 虚拟机的垃圾收集机制结合。
    • **统计信息:**提供缓存命中率、平均加载时间、自动回收计数等统计信息。
    • **持久化功能:**将缓存内容存储到数据库或磁盘中。

7、分布式缓存与本地缓存打配合

(1)分布式缓存的形式
  • 复制式缓存
    • **特点:**每个节点都有完整的数据副本,读取性能高,但写入性能随节点数增加而急剧下降。
    • **代表性产品:**JBossCache
    • **适用场景:**很少更新但频繁读取的数据。
  • 集中式缓存
    • **特点:**数据集中存储,读写都需要网络访问,不会随节点数增加而增加负担,但性能低于进程内缓存。
    • **代表性产品:**Redis、Memcached
    • **适用场景:**更新和读取都较为频繁的数据。
(2)数据一致性
  • **AP(可用性和分区容忍性):**如 Redis,高性能、高可用,但不保证强一致性。
  • **CP(一致性和分区容忍性):**如 ZooKeeper、Doozerd、Etcd,保证强一致性,但吞吐量有限。
(3)透明多级缓存
  • **概念:**结合进程内缓存和分布式缓存,形成多级缓存系统。
  • **优点:**结合两者优点,提高整体性能。
  • **挑战:**代码侵入性大,管理复杂,容易出现数据不一致问题。
  • 解决方案:
    • **变更以分布式缓存为准:**数据变动时,通过通知机制使各节点的一级缓存失效。
    • **访问以进程内缓存优先:**优先查询一级缓存,未命中再查询二级缓存。
(4)缓存风险及应对措施
  • 缓存穿透
    • **现象:**查询不存在的数据,每次都触及数据库。
    • 应对措施:
      • **缓存空值:**对返回为空的 Key 值进行缓存,设置较短的超时时间。
      • **布隆过滤器:**在缓存前设置布隆过滤器,过滤掉不存在的 Key 值。
  • 缓存击穿
    • **现象:**热点数据失效,大量请求同时到达数据库。
    • 应对措施:
      • **加锁同步:**使用互斥锁或分布式锁,确保只有一个请求能访问数据源。
      • **手动管理热点数据:**通过代码有计划地更新和失效热点数据。
  • 缓存雪崩
    • **现象:**大量数据在同一时间失效,导致请求大量到达数据库。
    • 应对措施:
      • **透明多级缓存:**分散数据的过期时间。
      • **随机过期时间:**将缓存的生存期设置为一个时间段内的随机时间。
  • 缓存污染
    • **现象:**缓存中的数据与数据源不一致。
    • 应对措施:
      • Cache Aside 模式:
        • **读数据:**先读缓存,未命中再读数据源并回填缓存。
        • **写数据:**先写数据源,再失效缓存。
相关推荐
子兮曰6 小时前
后端字段又改了?我撸了一个 BFF 数据适配器,从此再也不怕接口“屎山”!
前端·javascript·架构
卓卓不是桌桌8 小时前
如何优雅地处理 iframe 跨域通信?这是我的开源方案
javascript·架构
Qlly8 小时前
DDD 架构为什么适合 MCP Server 开发?
人工智能·后端·架构
用户881586910911 天前
AI Agent 协作系统架构设计与实践
架构
鹏北海1 天前
Qiankun 微前端实战踩坑历程
前端·架构
货拉拉技术1 天前
货拉拉海豚平台-大模型推理加速工程化实践
人工智能·后端·架构
RoyLin1 天前
libkrun 深度解析:架构设计、模块实现与 Windows WHPX 后端
架构
CoovallyAIHub2 天前
实时视觉AI智能体框架来了!Vision Agents 狂揽7K Star,延迟低至30ms,YOLO+Gemini实时联动!
算法·架构·github
RoyLin2 天前
领域驱动设计:回归本质的工程实践
架构
CoovallyAIHub2 天前
OpenClaw:从“19万星标”到“行业封杀”,这只“赛博龙虾”究竟触动了谁的神经?
算法·架构·github