后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载导读延迟是面向用户的高并发系统中影响收入与体验的核心指标。本文以 System Design 101 仓库中 Top 5 Strategies to Reduce Latency 一文为主线完整覆盖数据库索引、缓存、负载均衡、CDN、异步处理与数据压缩六大策略并结合仓库内相关文档逐层展开原理、适用场景与工程注意事项。读完本文你将掌握一套可落地的高延迟问题排查与优化路径并能在系统设计面试中条理清晰地阐述延迟优化的权衡取舍。为什么延迟优化如此重要10 年前Amazon 的研究发现每 100ms 的延迟增加会带来约 1% 的销售额损失——按今天的规模换算这相当于 57 亿美元的营收流失。这个数字揭示了延迟与商业收入的直接相关性对于面向海量用户的前端系统高延迟不是体验问题而是真金白银的收益损失。从系统设计的角度看一次用户请求的端到端延迟由多个环节累加而成可以参考仓库中 Which Latency Numbers Should You Know 一文给出的数量级参考注意这些数字基于 Jeff Dean 的经典数据与其他在线基准并非精确值操作数量级典型场景L1/L2 缓存访问1 ns / 10 ns内置于微处理器芯片一般无需关心RAM 内存访问100 ns读取 Redis 等内存数据存储1Gbps 网络发送 1KB 数据10 us从 Memcached 经网络取数SSD 顺序读取100 usRocksDB 等基于磁盘的 K/V 存储数据库写入insert1 msPostgreSQL commit存数据、建索引、刷日志跨洲网络传输如美西往返100 ms长距离视频会议可以看到从内存读到数据库写入再到跨洲网络传输延迟跨越了 6 个数量级。降延迟的核心思路就是把请求尽量留在延迟数量级更小的环节这正是下面六大策略的共同目标。策略一数据库索引Database Indexing数据库通常是请求链路中延迟最高的环节之一。索引的核心价值是加速数据检索让数据库无需全表扫描即可定位目标记录。索引的使用要点与代价根据仓库中 A Cheatsheet on Database Performance 的总结索引优化需要注意目的加快数据检索速度减少查询时的扫描成本副作用过度索引会拖慢写入——每次 insert/update 都要同步维护所有索引结构最佳实践定期审查并优化现有索引删除冗余索引为高频查询条件建立合适的复合索引。与查询优化配合索引本身不是银弹需要与查询优化配套使用使用EXPLAIN分析查询计划确认查询是否命中了预期索引避免SELECT *只取所需字段减少数据传输量编写高效的WHERE子句尽量让过滤条件可以利用索引。适用场景读多写少的查询链路高频点查按主键或唯一键查询优先建索引。注意事项写密集场景要克制加索引的冲动索引不是越多越好。策略二缓存Caching缓存是用空间换时间的经典手段把热数据放到比数据库快几个数量级的存储如 Redis中。回到上面的延迟表内存读取约 100 ns而数据库写入约 1 ms两者相差约 1 万倍。引入缓存后的数据同步问题引入缓存后缓存与数据库之间的数据同步就不可避免。仓库中 Top 5 Caching Strategies 与 Top Caching Strategies 两文系统整理了五种读写策略读策略Read StrategiesCache Aside旁路缓存应用先查缓存命中直接返回未命中则查数据库、回填缓存。这是最常用、最灵活的模式应用对缓存生命周期有完全控制权Read Through读穿透应用只与缓存交互缓存组件在未命中时负责从数据库加载数据并回填逻辑由缓存层封装。写策略Write StrategiesWrite Around绕写直接写数据库不更新缓存通常与 Cache Aside 配合——等到下次读未命中时再回填缓存避免写操作污染缓存Write Back回写先写缓存由缓存异步批量落库。写入延迟低、吞吐高但存在缓存故障时数据丢失的风险Write Through直写写数据库的同时同步更新缓存保证一致性但每次写都要同时操作两处写路径延迟更高。关键结论五种策略经常组合使用。例如write-around 常与 cache-aside 搭配既保证缓存最终一致又不拖慢写路径。选择哪种组合取决于业务对读写延迟、数据一致性与丢失容忍度的要求。适用场景热数据读多写少、容忍一定延迟的一致性、请求热点集中。注意事项缓存引入后要关注缓存一致性、缓存穿透/击穿/雪崩等失效场景可参考仓库中 Things to Consider When Using Cache 与 How Can Cache Systems Go Wrong 的讨论。策略三负载均衡Load Balancing负载均衡是分布式系统的流量调度中枢。仓库中 What is a Load Balancer 给出的定义是将网络或应用流量分发到多台服务器上的设备或软件。它通过水平扩展分摊单点压力避免单个实例成为延迟瓶颈。负载均衡的核心职责分发流量将请求均匀/按策略分配到多个后端实例保证可用性与可靠性对后端做健康检查故障实例自动摘除提升性能避免单机过载缩短响应时间扩展应用通过加机器即可平滑扩容。负载均衡的类型按部署形态硬件负载均衡专用物理设备软件负载均衡部署在标准硬件或虚拟机上的应用云负载均衡云厂商内置服务如 AWS ELB、Google Cloud Load Balancing、Azure Load Balancer。按 OSI 层级Layer 4传输层基于 IP 地址与 TCP/UDP 端口做转发决策性能高、可处理任意协议Layer 7应用层基于 HTTP 内容URL、Header、Cookie做路由支持更细粒度的控制GSLB全局负载均衡跨地域分发流量在提升性能的同时增强冗余。六大负载均衡算法仓库中 Top 6 Load Balancing Algorithms 将算法分为静态与动态两类静态算法Round Robin轮询请求按顺序轮流发给各个实例要求后端基本无状态Sticky Round Robin粘性轮询轮询的改进版——若 Alice 的第一个请求到了服务 A后续请求也继续发给 A保证会话亲和Weighted Round Robin加权轮询管理员为每个实例配置权重权重高的实例承接更多请求适合异构实例Hash对请求的 IP 或 URL 做哈希按哈希结果路由到固定实例可用于一致性缓存。动态算法Least Connections最少连接新请求发给当前并发连接数最少的实例Least Response Time最短响应时间新请求发给响应最快的实例兼顾当前负载与实例性能。适用场景任何需要横向扩展、消除单点瓶颈的服务层。注意事项粘性与哈希类算法会牺牲一定的均衡性需要在会话亲和与均匀分布之间取舍。策略四内容分发网络CDNCDN 解决的是物理距离带来的延迟问题。仓库中 What is CDN (Content Delivery Network) 的定义CDN 是地理分布式的服务器边缘服务器集合用于快速交付静态与动态内容。用户无需每次都从源站取内容而是从离自己最近的 CDN 节点获取缓存副本。CDN 的四大收益降低延迟边缘节点就近服务缩短物理距离降低带宽成本源站压力大幅减轻静态资源流量被边缘化提升安全性尤其是对 DDoS分布式拒绝服务攻击的防护提高内容可用性即使源站抖动边缘缓存仍可持续服务。CDN 的请求流程与架构根据仓库中 Why are Content Delivery Networks (CDN) so Popular 的梳理一次 CDN 请求的完整链路为用户设备在 DNS 解析后将内容请求发送到最近的 CDN 边缘服务器边缘服务器先查本地缓存命中则直接返回未命中则边缘服务器把请求转发给源站Origin Server拿到内容后边缘服务器在本地缓存一份副本再交付给用户。CDN 架构的核心组件包括源站内容的原始来源、边缘服务器全球分布、面向用户缓存与服务、DNS把域名解析到最近边缘节点的 IP与控制平面负责配置与管理边缘服务器。CDN 的请求路由技术GSLB综合地理邻近度、服务器负载与网络状况等因素路由用户请求Anycast DNS让多台服务器共享同一 IP自动将流量导向最近的数据中心互联网交换中心IXPCDN 服务商在主要 IXP 建立接入点与 ISP 及其他网络直连交换流量进一步缩短路径。适用场景静态资源图片、视频、JS/CSS、全球用户分发、对源站的 DDoS 防护。注意事项动态内容的缓存策略需谨慎设置 TTL可参考仓库中 A Beginners Guide to CDN 与 How Does CDN Work 深入了解实现细节。策略五异步处理Async Processing同步链路中慢操作如发送邮件、生成报表、写日志会直接阻塞用户请求。异步处理把耗时操作从请求关键路径中剥离通过消息队列削峰填谷让请求立即返回从而大幅降低用户可感知延迟。消息队列与 Kafka 的角色仓库中 Types of Message Queues 用邮局比喻消息队列它帮助程序之间有序通信选择消息队列时需考察速度、可扩展性、可靠性、持久性、易用性、生态、集成与协议支持等维度。Kafka 最初就是为海量日志处理而生的消息保留到过期为止消费端按自己的节奏拉取消息。它的典型使用场景见 Top 5 Kafka Use Cases包括日志处理与分析推荐系统中的数据流系统监控与告警CDC变更数据捕获系统迁移。异步化为何能快顺序 I/O 与零拷贝Kafka 的高吞吐底层依赖两个关键设计详见 Why is Kafka Fast顺序 I/OKafka 大量依赖磁盘的顺序读写避免了随机 I/O 的寻道开销使磁盘也能达到接近内存的吞吐。零拷贝Zero Copy对比普通读取路径数据需要经历磁盘 → OS 缓存 → Kafka 应用 → Socket 缓冲区 → 网卡多次拷贝而启用零拷贝后数据从 OS 缓存直接经sendfile()拷贝到网卡跳过了用户态与内核态之间的多次复制显著降低 CPU 开销与拷贝延迟。适用场景请求路径中存在不需要即时返回的耗时任务突发流量需要削峰需要解耦上下游生产者与消费者。注意事项异步化会引入最终一致性与失败重试问题需要配套消息可靠投递与幂等消费设计。策略六数据压缩Data Compression当数据必须走网络传输时减小载荷体积就是缩短传输时间。仓库中 Top 5 Common Ways to Improve API Performance 明确指出对请求与响应进行压缩如 gzip可以显著加快上传与下载过程。压缩的收益来源网络传输延迟与数据体积成正比压缩后字节数减少跨地域链路收益尤其明显静态资源HTML/JS/CSS/JSON文本压缩率高通常在 60%~80% 以上与 CDN 结合时边缘节点可对内容做压缩与转码进一步降低回源与下行带宽。与相关优化手段的组合使用同一文档还给出了与压缩配套的另外几种 API 性能优化手段可以形成组合拳结果分页Result Pagination对大结果集流式分页返回提升响应速度与用户体验异步日志Asynchronous Logging日志先写入无锁缓冲区立即返回周期性刷盘显著降低每次调用的磁盘 I/O 开销连接池Connection Pooling复用一组打开的数据库连接避免每次交互都新建/销毁连接的开销。适用场景文本类响应载荷较大、网络带宽受限、移动端弱网环境。注意事项压缩需权衡 CPU 开销与传输节省对极小载荷压缩头开销可能得不偿失需在服务端与客户端同时启用并协商压缩算法。总结降延迟策略的选择框架将六大策略与延迟发生在哪个环节对应起来可以形成一张优化决策图策略优化的环节典型工具/技术代价与权衡数据库索引数据检索BTree 索引、EXPLAIN 调优过度索引拖慢写入缓存数据读取Redis/Memcached、Cache Aside 等一致性、缓存失效场景负载均衡服务端吞吐与冗余L4/L7 均衡器、GSLB、六大算法会话亲和 vs 均衡性CDN网络传输距离边缘节点、Anycast、IXP动态内容缓存策略异步处理请求关键路径消息队列、Kafka顺序 I/O 零拷贝最终一致性与重试数据压缩网络传输体积gzip、分页、连接池、异步日志CPU 开销 vs 带宽节省在实际系统中六大策略并非互斥而是层层叠加CDN 把静态内容拉到用户身边负载均衡把流量摊平到多实例缓存把热点数据留在内存索引让数据库查询更快异步处理把慢任务移出关键路径压缩让剩下必须传输的数据变小。排查高延迟问题时建议按照先看传输CDN/压缩再看读路径索引/缓存最后看架构负载均衡/异步化的顺序逐层分析用可观测指标验证每一步的收益。更完整的系统设计素材可继续阅读本仓库 data/guides 目录下同主题的扩展文档Which Latency Numbers Should You Know延迟数量级速查、Top 5 Caching Strategies缓存同步策略、What is a Load Balancer负载均衡详解与 A Cheatsheet on Database Performance数据库性能速查。赞分享后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载相关推荐System Design 101 云成本削减实战指南六大降本策略与资源优化全景System Design 101 云成本削减实战指南六大降本策略与资源优化全景 非理性的云成本支出Irrational Cloud Cost是许多组织在后端文档教程5分钟上手crypto-browserify快速实现浏览器端SHA256哈希与HMAC签名5分钟上手crypto browserify快速实现浏览器端SHA256哈希与HMAC签名 crypto browserify是一个为浏览器环境提供Node.密码学system-design-101 数据管理六大模式详解从旁路缓存到分片的实战指南system design 101 数据管理六大模式详解从旁路缓存到分片的实战指南 本文基于仓库文档 data/guides/how do we manage后端文档教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考