{"name":"高并发","id":"软件工程-架构-系统设计-高并发","content":"# 高并发系统设计\n\n## 高并发的本质：系统性矛盾与工程妥协\n\n### 高并发不只是”快”\n\n高并发问题的本质，不单是追求”快”，而是在资源受限条件下：\n\n* **有限资源** 与 **无限请求** 之间的矛盾\n* **强一致性** 与 **系统吞吐 / 延迟** 之间的冲突\n* **实时计算** 与 **可预测稳定性** 之间的权衡\n\n因此，高并发系统设计是一门：\n\n> 在资源受限前提下，对请求进行**调度、延迟、削峰、分摊与取舍**的工程学。\n\n### 高并发的权衡\n\n1. **时空换时空**：缓存、预计算、异步化\n2. **空间换并行**：拆分、分片、扩容\n3. **一致性换可用性**：最终一致、读写分离、延迟容忍\n\n## 吞吐放大能力：让系统”接得住”\n\n### 水平扩展\n\n**抽象模型**：\n\n- 拆分（定义边界）\n- 无状态（消除绑定）\n- 负载均衡（流量分发）\n\n**解决问题**：使系统具备**横向伸缩能力**，突破单机性能上限。\n\n**代价**：协调复杂度上升、分布式一致性挑战、运维成本增加\n\n**本质**：水平扩展的本质是**用更多的节点换更强的单机处理能力**，核心在于重构系统内部的协作关系，而非堆砌节点。\n\n### 批量化处理\n\n**设计原则**：减少单位请求的系统调用与 IO 次数。\n\n* 批量写入\n* 合并小操作\n* 管道化处理\n\n代价：延迟上升、实时性下降。\n\n**核心原理**：把多次IO合并为一次，降低单位请求的边际成本。\n\n## 请求消化能力：让系统“吃得掉”\n\n### 缓存体系\n\n**抽象模型**：\n\n* 多级缓存（本地 → 分布式 → CDN）\n\n**解决问题**：\n\n* 将热点请求挡在慢资源（数据库）之前\n\n**系统性风险**：\n\n* 缓存雪崩\n* 缓存击穿\n* 缓存穿透\n\n缓存设计本质是**一致性与性能的权衡**。\n\n\n### 异步化与消息队列\n\n**设计原则**：\n\n* 请求与处理解耦\n* 峰值写入转化为平稳消费\n\n**抽象能力**：\n\n* 削峰填谷\n* 解耦系统\n* 延迟容忍\n\n代价：\n\n* 系统复杂度上升\n* 需要处理重复、乱序、幂等\n\n\n### 预计算\n\n**设计原则**：\n\n* 把“实时复杂计算”前移到写路径\n\n适用于：\n\n* 读远多于写\n* 计算成本远高于存储成本的场景\n* 数据可接受一定延迟\n\n\n## 等待与调度能力：承认资源有限\n\n### 排队系统\n\n* 显式排队（队列、等待页）\n* 隐式排队（线程池、连接池）\n\n排队是对“资源有限”的正面承认。\n\n\n### 限流与配额\n\n**核心目标**：\n\n* 防止系统被瞬时流量压垮\n\n**典型模型**：\n\n* 令牌桶\n* 漏桶\n\n限流策略本质是**服务质量管理（QoS）**。\n\n\n## 一致性妥协能力：读写分离与最终一致\n\n### 读写分离\n\n**设计动机**：\n\n* 读多写少场景下，缓解主库压力\n\n**核心问题**：\n\n* 复制延迟\n\n**工程应对**：\n\n* 核心路径读主\n* 非核心路径容忍旧数据\n\n\n### 最终一致性\n\n高并发系统往往主动放弃强一致，换取：\n\n* 更高吞吐\n* 更好可用性\n\n## 高并发系统的演进路径\n\n1. **早期阶段**：单体 + 缓存 + 性能优化\n2. **成长阶段**：系统拆分 + 异步化\n3. **规模阶段**：分片 + 读写分离 + 治理体系\n4. **成熟阶段**：稳定性优先、最终一致\n\n> 高并发设计没有\"最优解\"，只有\"阶段最优解\"。\n\n## 架构认知误区\n\n高并发设计中，常见的认知偏差会导致错误的架构决策。\n\n### 唯工具论\n\n把缓存、消息队列、分库分表当作高并发的银弹，不评估场景直接套用。\n\n**本质**：把手段当目的，工具导向而非问题导向\n\n高并发设计应先定位瓶颈——是计算、存储还是网络？瓶颈不同，解决方案不同。工具选型应该是问题导向，而非趋势导向。\n\n### 扩容方向迷信\n\n认为\"加机器就能解决高并发\"，不先定位瓶颈在哪一层。\n\n**本质**：计算层的扩展解决不了存储层的瓶颈\n\n如果瓶颈在数据库，加应用服务器毫无帮助；如果瓶颈在热点数据竞争，扩容反而加剧资源争抢。\n\n### 缓存万能论\n\n认为缓存能解决所有性能问题，忽视缓存自身的风险与维护成本。\n\n**本质**：缓存省了数据库访问，但没算缓存的一致性维护成本\n\n缓存有三大固有风险：雪崩（批量失效）、击穿（热点key过期）、穿透（恶意查询不存在数据）。引入缓存时必须同步考虑这些风险的应对方案。\n\n### 延迟忽视论\n\n只关注吞吐量，忽视响应时间的分布特征。\n\n**本质**：平均值掩盖长尾，高并发下长尾用户才是多数\n\nP99 等分位值决定了用户的真实体验。平均值好看不等于高并发下用户体验过关。\n\n### 复杂度失配\n\n低并发场景引入高并发架构，或高并发场景用简单方案。\n\n**本质**：架构复杂度应与业务量级、团队规模相匹配\n\nQPS 几十的低并发场景强行上微服务、分布式缓存，复杂度成本远超收益。反之，千万级流量的场景用单体架构必然崩盘。\n\n**认知闭环**：高并发架构的决策顺序应该是——先定位瓶颈，再评估量级与读写比例，再明确一致性需求，最后才选择技术手段。\n\n## 关联内容（自动生成）\n\n- [/软件工程/架构/系统设计/缓存.md](/软件工程/架构/系统设计/缓存.md) 缓存是高并发系统设计中的核心技术手段，用于解决有限资源与无限请求之间的矛盾，通过时间换空间策略提升系统性能\n- [/软件工程/架构/系统设计/可用性.md](/软件工程/架构/系统设计/可用性.md) 高可用性是高并发系统的重要组成部分，涉及熔断、降级等系统保护机制，确保系统在高负载下的稳定运行\n- [/软件工程/架构/系统设计/扩展性.md](/软件工程/架构/系统设计/扩展性.md) 扩展性是高并发系统设计的关键能力之一，通过系统拆分、负载均衡等手段实现系统的横向扩展\n- [/软件工程/架构/系统设计/流量控制.md](/软件工程/架构/系统设计/流量控制.md) 流量控制是高并发系统中的重要环节，包含限流、排队等调度能力，防止系统被瞬时流量压垮\n- [/软件工程/架构/系统设计/分布式/分布式系统.md](/软件工程/架构/系统设计/分布式/分布式系统.md) 分布式系统是解决高并发问题的重要架构模式，通过空间换并行的策略提升系统整体处理能力\n- [/软件工程/架构/系统设计/可观测性.md](/软件工程/架构/系统设计/可观测性.md) 可观测性是高并发系统治理能力的重要组成部分，提供监控、链路追踪等手段帮助理解和优化系统性能\n- [/软件工程/架构/系统设计/网关.md](/软件工程/架构/系统设计/网关.md) 网关作为系统的入口，在高并发场景下承担着负载均衡、限流、熔断等关键职责\n- [/软件工程/架构/系统设计/伸缩性.md](/软件工程/架构/系统设计/伸缩性.md) 伸缩性与高并发系统设计紧密相关，涉及系统如何根据负载情况动态调整资源分配\n- [/中间件/web中间件/Nginx.md](/中间件/web中间件/Nginx.md) Nginx作为常用的负载均衡和反向代理工具，在高并发系统架构中发挥重要作用\n- [/中间件/数据库/数据库优化.md](/中间件/数据库/数据库优化.md) 数据库优化是高并发系统设计中的关键环节，涉及分库分表、读写分离等策略\n- [/中间件/消息队列/消息队列.md](/中间件/消息队列/消息队列.md) 消息队列是高并发系统中实现异步化和削峰填谷的重要组件\n- [/操作系统/linux/Linux性能优化.md](/操作系统/linux/Linux性能优化.md) 系统层面的性能优化是高并发系统设计的基础，涉及资源管理和调度优化\n- [/软件工程/架构/系统设计/混沌工程.md](/软件工程/架构/系统设计/混沌工程.md) 混沌工程通过主动注入故障来验证高并发系统的稳定性和韧性\n- [/软件工程/微服务/服务治理/服务治理.md](/软件工程/微服务/服务治理/服务治理.md) 微服务架构下的服务治理机制对于构建高并发系统至关重要\n","metadata":"tags: ['计算机系统', '并发编程', '性能', '分布式系统']\nbooks: [\n\t{name: '深入分析Java Web技术内幕'}\n]","hasMoreCommit":true,"totalCommits":24,"commitList":[{"date":"2026-05-27T10:08:04+08:00","author":"MY","message":"doc(性能工程): 重构文档","hash":"2e3648b1dc0bf9be8e1790389811bdd99e878f29"},{"date":"2026-03-31T17:49:31+08:00","author":"MY","message":"docs(architecture): 更新高并发系统设计文档结构和内容","hash":"586110aba9c10b89c7754440637dc10b9c0a392c"},{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2026-01-21T17:39:58+08:00","author":"MY","message":"docs(system-design): 更新高并发系统设计文档并添加相关图片资源","hash":"cb8300b799c28e3ffd58dd7ac3af5b717c61c6dc"},{"date":"2025-11-27T19:59:51+08:00","author":"MY","message":"docs: 调整多个文档中的链接格式与内容排版 - 统一去除部分链接的 Markdown 文件后缀（.md） - 修正不一致的列表项格式和缩进问题 - 删除冗余或错误的文件引用路径 - 提升文档可读性与内部跳转准确性","hash":"b81b0f366a2079be0ad09074488f23c13cb51615"},{"date":"2024-11-22T10:11:46+08:00","author":"MY","message":"📦伸缩性","hash":"200aa0a73291a296032cf358327b73c387f0662f"},{"date":"2024-11-21T17:01:26+08:00","author":"MY","message":"📦高并发","hash":"819b8838c0173819d23b03b67f4f6e9aa22123f0"},{"date":"2023-01-16T14:42:20+08:00","author":"cjiping","message":"📦数据库","hash":"28000b081b4f987f0343c41be793307aedb6addf"},{"date":"2022-08-11T21:50:32+08:00","author":"MY","message":"✏️高并发&可用性","hash":"7ab1e83653b1b3901139699204604ab974fabf57"},{"date":"2022-05-06T21:43:14+08:00","author":"MY","message":"✏️更新 架构","hash":"925779837e7929344533f39572e8aa1c71a0363f"}],"createTime":"2020-03-16T21:05:42+08:00"}