docs(architecture): 更新高并发系统设计文档结构和内容

重构高并发系统设计文档，简化章节结构，更新核心概念描述，
修正术语表达，增强内容准确性。

主要变更包括：
- 简化章节标题层级结构
- 更新高并发本质描述，强调资源受限条件下的权衡
- 重构三大核心手段表述，统一术语
- 简化系统能力模型展示
- 更新批量化处理和缓存体系说明
- 补充架构认知误区分析
- 优化一致性妥协能力和调度能力描述

Author: 0xcaffebabe

doc/软件工程/架构/系统设计/高并发.md

@@ -7,105 +7,43 @@ books: [
 
 # 高并发系统设计
 
-## 一、高并发的本质：系统性矛盾与工程妥协
+## 高并发的本质：系统性矛盾与工程妥协
 
-### 1. 高并发并不是“快”
+### 高并发不只是”快”
 
-高并发问题的本质，并非单点性能不足，而是：
+高并发问题的本质，不单是追求”快”，而是在资源受限条件下：
 
 * **有限资源** 与 **无限请求** 之间的矛盾
 * **强一致性** 与 **系统吞吐 / 延迟** 之间的冲突
 * **实时计算** 与 **可预测稳定性** 之间的权衡
 
 因此，高并发系统设计是一门：
 
-> 在资源受限前提下，对请求进行**调度、延迟、削峰、分摊与妥协**的工程学。
+> 在资源受限前提下，对请求进行**调度、延迟、削峰、分摊与取舍**的工程学。
 
----
-
-### 2. 高并发设计的三大核心手段
-
-所有高并发技术手段，最终都可归结为三类：
+### 高并发的权衡
 
-1. **时间换空间**：缓存、预计算、异步化
+1. **时空换时空**：缓存、预计算、异步化
 2. **空间换并行**：拆分、分片、扩容
 3. **一致性换可用性**：最终一致、读写分离、延迟容忍
 
----
-
-## 二、高并发系统能力模型（核心抽象）
-
-高并发系统并非“堆技术”，而是构建一组稳定能力。
-
-```
-高并发系统能力模型
-├─ 吞吐放大能力
-│  ├─ 横向扩展（拆分 / 扩容）
-│  ├─ 负载均衡
-│  └─ 批量化处理
-├─ 峰值削减能力
-│  ├─ 缓存体系
-│  ├─ 异步化 / MQ
-│  └─ 预计算（重写轻读）
-├─ 等待与调度能力
-│  ├─ 排队系统
-│  ├─ 限流（令牌桶 / 漏桶）
-│  └─ 优先级与配额
-├─ 一致性妥协能力
-│  ├─ 读写分离
-│  ├─ 最终一致
-│  └─ 延迟容忍
-├─ 稳定性与治理能力
-│  ├─ 熔断 / 降级
-│  ├─ 可观测性（监控 / APM）
-│  └─ 弹性扩缩容
-```
-
-后续章节将围绕该能力模型展开。
-
----
-
-## 三、吞吐放大能力：让系统“接得住”
-
-### 1. 系统拆分（空间换并行）
+## 吞吐放大能力：让系统”接得住”
 
-**设计原则**：避免所有请求竞争同一资源。
+### 水平扩展
 
 **抽象模型**：
 
-* 将单体系统拆分为多个**低耦合子系统**
-* 每个子系统拥有独立资源边界（数据库、线程池、缓存）
-
-**拆分维度**：
-
-* 业务维度（领域边界）
-* 功能维度（职责单一）
-* 资源维度（冷热分离、轻重分离）
-
-> 拆分不是一次性行为，而是伴随业务复杂度增长的持续过程。
+- 拆分（定义边界）
+- 无状态（消除绑定）
+- 负载均衡（流量分发）
 
----
-
-### 2. 负载均衡（请求分摊机制）
-
-**设计原则**：任何可横向扩展的能力，必须配合负载均衡。
-
-**抽象层级**：
-
-* 链路级：DNS
-* 网络级：四层负载均衡（LVS）
-* 应用级：七层负载均衡（Nginx / Gateway）
-* 客户端级：客户端感知与服务发现
-
-**负载均衡算法本质分类**：
+**解决问题**：使系统具备**横向伸缩能力**，突破单机性能上限。
 
-* 任务均分（轮询 / 随机）
-* 压力感知（最少连接 / 响应时间）
-* 状态绑定（一致性哈希）
+**代价**：协调复杂度上升、分布式一致性挑战、运维成本增加
 
----
+**本质**：水平扩展的本质是**用更多的节点换更强的单机处理能力**，核心在于重构系统内部的协作关系，而非堆砌节点。
 
-### 3. 批量化处理
+### 批量化处理
 
 **设计原则**：减少单位请求的系统调用与 IO 次数。
 
@@ -115,11 +53,11 @@ books: [
 
 代价：延迟上升、实时性下降。
 
----
+**核心原理**：把多次IO合并为一次，降低单位请求的边际成本。
 
-## 四、峰值削减能力：让系统“慢慢消化”
+## 请求消化能力：让系统“吃得掉”
 
-### 1. 缓存体系（时间换空间）
+### 缓存体系
 
 **抽象模型**：
 
@@ -137,9 +75,8 @@ books: [
 
 缓存设计本质是**一致性与性能的权衡**。
 
----
 
-### 2. 异步化与消息队列
+### 异步化与消息队列
 
 **设计原则**：
 
@@ -157,9 +94,8 @@ books: [
 * 系统复杂度上升
 * 需要处理重复、乱序、幂等
 
----
 
-### 3. 预计算（重写轻读）
+### 预计算
 
 **设计原则**：
 
@@ -169,21 +105,20 @@ books: [
 
 * 读远多于写
 * 计算成本远高于存储成本的场景
+* 数据可接受一定延迟
 
----
 
-## 五、等待与调度能力：承认资源有限
+## 等待与调度能力：承认资源有限
 
-### 1. 排队系统
+### 排队系统
 
 * 显式排队（队列、等待页）
 * 隐式排队（线程池、连接池）
 
 排队是对“资源有限”的正面承认。
 
----
 
-### 2. 限流与配额
+### 限流与配额
 
 **核心目标**：
 
@@ -196,11 +131,10 @@ books: [
 
 限流策略本质是**服务质量管理（QoS）**。
 
----
 
-## 六、一致性妥协能力：读写分离与最终一致
+## 一致性妥协能力：读写分离与最终一致
 
-### 1. 读写分离
+### 读写分离
 
 **设计动机**：
 
@@ -215,64 +149,68 @@ books: [
 * 核心路径读主
 * 非核心路径容忍旧数据
 
----
 
-### 2. 最终一致性
+### 最终一致性
 
 高并发系统往往主动放弃强一致，换取：
 
 * 更高吞吐
 * 更好可用性
 
----
+## 高并发系统的演进路径
 
-## 七、稳定性与治理能力：系统长期可用的前提
+1. **早期阶段**：单体 + 缓存 + 性能优化
+2. **成长阶段**：系统拆分 + 异步化
+3. **规模阶段**：分片 + 读写分离 + 治理体系
+4. **成熟阶段**：稳定性优先、最终一致
 
-### 1. 可观测性
+> 高并发设计没有"最优解"，只有"阶段最优解"。
 
-* 指标监控（资源 / 延迟 / 错误率）
-* 链路追踪
-* 业务监控
+## 架构认知误区
 
-> 没有可观测性，就没有可治理性。
+高并发设计中，常见的认知偏差会导致错误的架构决策。
 
----
+### 唯工具论
 
-### 2. 熔断与降级
+把缓存、消息队列、分库分表当作高并发的银弹，不评估场景直接套用。
 
-**设计原则**：
+**本质**：把手段当目的，工具导向而非问题导向
 
-* 局部失败不可扩散
+高并发设计应先定位瓶颈——是计算、存储还是网络？瓶颈不同，解决方案不同。工具选型应该是问题导向，而非趋势导向。
 
-降级不是失败，而是**系统自我保护机制**。
+### 扩容方向迷信
 
----
+认为"加机器就能解决高并发"，不先定位瓶颈在哪一层。
 
-### 3. 弹性扩缩容
+**本质**：计算层的扩展解决不了存储层的瓶颈
 
-* 通过监控数据触发
-* 本质是资源与负载的动态匹配
+如果瓶颈在数据库，加应用服务器毫无帮助；如果瓶颈在热点数据竞争，扩容反而加剧资源争抢。
 
----
+### 缓存万能论
 
-## 八、高并发系统的演进路径
+认为缓存能解决所有性能问题，忽视缓存自身的风险与维护成本。
 
-1. **早期阶段**：单体 + 缓存 + 性能优化
-2. **成长阶段**：系统拆分 + 异步化
-3. **规模阶段**：分片 + 读写分离 + 治理体系
-4. **成熟阶段**：稳定性优先、最终一致
+**本质**：缓存省了数据库访问，但没算缓存的一致性维护成本
 
-> 高并发设计没有"最优解"，只有"阶段最优解"。
+缓存有三大固有风险：雪崩（批量失效）、击穿（热点key过期）、穿透（恶意查询不存在数据）。引入缓存时必须同步考虑这些风险的应对方案。
 
----
+### 延迟忽视论
+
+只关注吞吐量，忽视响应时间的分布特征。
+
+**本质**：平均值掩盖长尾，高并发下长尾用户才是多数
+
+P99 等分位值决定了用户的真实体验。平均值好看不等于高并发下用户体验过关。
+
+### 复杂度失配
+
+低并发场景引入高并发架构，或高并发场景用简单方案。
 
-## 结语：从技术堆叠到系统认知
+**本质**：架构复杂度应与业务量级、团队规模相匹配
 
-高并发系统设计的核心能力：
+QPS 几十的低并发场景强行上微服务、分布式缓存，复杂度成本远超收益。反之，千万级流量的场景用单体架构必然崩盘。
 
-* 是否理解系统瓶颈出现在哪里
-* 是否清楚每一次性能提升背后的代价
-* 是否具备在一致性、延迟、成本之间做选择的能力
+**认知闭环**：高并发架构的决策顺序应该是——先定位瓶颈，再评估量级与读写比例，再明确一致性需求，最后才选择技术手段。
 
 ## 关联内容（自动生成）