《后端架构设计》是一套四卷本：卷一《架构基础与边界》、卷二《高性能与高可用》、卷三《分布式与数据一致性》、卷四《演进与治理》。本页是卷二的完整目录，共 45 篇。
卷二接着卷一的模块化单体基线往下问：它到底能扛多少流量、延迟花在哪里、过载时哪些请求该被拒绝、故障时怎样把影响关在局部、变更时怎样退得回来。每篇至少包含一个可运行的 arch-lab 组件、一次带命令与输出的测量、一份带退出条件的决策表，或一组 Go/Java 21 对照。
全书概览
| 项目 | 内容 |
|---|---|
| 书稿 | 《后端架构设计·高性能与高可用》 |
| 篇数 | 45 篇（13 章 × 3 节 + 序、前言、目录、附录 A–C） |
| 主线项目 | arch-lab：Go 1.26 订单交易系统 |
| 技术栈 | Go 1.26.0 主线；Java 21 对照 |
| 运行级别 | L1 默认；第 8、10、12、13 章至少各一个 L2；L3 只写实际跑过的部分 |
| 阅读方式 | 从目录与学习路径 进入顺序通读，或按下方路径跳读 |
| 上级专题 | 书稿专题 |
| 相关专题 | 架构设计 · 分布式系统 |
三条阅读路径
路径 A：从度量到验收（约 36 小时）
按章节顺序读。第 1–2 章建立度量与容量判断，第 3–7 章处理缓存、异步、资源池、限流熔断和超时重试，第 8–10 章讨论拓扑、发布与观测，第 11–13 章落到数据层、贯穿改造和验收。每章至少跑通一节 L1 代码。
路径 B：带着一次改造任务来（约 10 小时）
先读 1.2、2.1、12.1 建立基线与容量，再按改造手段跳读：加缓存读第 3 章，改异步读第 4 章，限流熔断读第 6 章，重试超时读第 7 章，最后用 12.3 的同口径对照和附录 C 的演练清单收尾。
路径 C：只关心线上故障（约 5 小时）
读 5.3、6.2、7.2、8.2、8.3、10.2、13.2，配合附录 B 的指标口径与附录 C 的演练检查表。重点是故障如何被观测、保护和恢复，不追求读完全部机制推导。
全书目录
前置与附录
| 篇 | 文章 | 核心内容 |
|---|---|---|
| 序 | 序 | 三个熟悉场景、卷一留下的问题、四个立场、arch-lab 延续与四卷分工 |
| 前言 | 前言 | 卷二新增组件、L1–L4 验收、代码标记、压测与故障注入口径、固定场景 |
| 目录 | 目录与学习路径 | 13 章依赖图、三条路径、症状表、章节速览与读完标准 |
| 附 A | 附录 A 压测工具与脚本 | loadgen 参数、输出字段、P1/P2 场景、流量回放、归档与十二条检查 |
| 附 B | 附录 B 性能指标速查 | 分位数与直方图合并、吞吐、排队、错误预算、SLO、公式与十种误读 |
| 附 C | 附录 C 故障演练检查表 | 十项准备、八个场景、中止与回滚、记录表、复盘与七条禁止事项 |
第一部分：度量与容量（第 1–2 章）
| 节 | 文章 | 核心内容 |
|---|---|---|
| 1.1 | 吞吐、延迟与尾部延迟 | 平均与分位数的差异、直方图、尾延迟的成因与观测口径 |
| 1.2 | 瓶颈定位：CPU、内存、I/O、锁 | 四类瓶颈的判定信号、pprof 使用与锁竞争的实测 |
| 1.3 | 性能预算：把端到端延迟拆到每个调用 | 顺序/并行/重试的预算算法、截止时间传播与降级优先级 |
| 2.1 | 从业务指标到 QPS 与并发数 | 日订单到峰值 QPS、利特尔法则与实例数估算 |
| 2.2 | 压测模型、数据与流量回放 | 开环/闭环差异、数据构造、脱敏与到达过程拟合 |
| 2.3 | 压测结果解读与容量余量 | 分位数合并、完成率与拒绝率、余量计算与结论边界 |
第二部分：缓存、异步与资源池（第 3–5 章）
| 节 | 文章 | 核心内容 |
|---|---|---|
| 3.1 | 本地缓存、分布式缓存与多级缓存 | 三级缓存结构、TTL/LRU、命中率与回源代价 |
| 3.2 | 缓存一致性、失效与更新策略 | 先删后写、延迟双删、订阅失效与版本号 |
| 3.3 | 穿透、击穿、雪崩与热 key 治理 | 空值缓存、singleflight、逻辑过期与热 key 拆分 |
| 4.1 | 同步改异步的收益与代价 | 延迟与一致性交换、失败补偿与用户体验 |
| 4.2 | 消息投递语义与消费幂等 | at-most/at-least/effectively-once 的责任边界与去重表 |
| 4.3 | 积压、顺序、死信与定时对账补偿 | 积压指标、分区顺序、死信处置与对账补齐 |
| 5.1 | 连接池、线程池与协程池 | 池容量计算、排队、超时与泄漏检测 |
| 5.2 | 舱壁隔离与资源配额 | 信号量舱壁、按调用方隔离与配额分配 |
| 5.3 | 慢调用与故障扩散 | 慢调用如何占满资源、传播路径与隔离验证 |
第三部分：过载治理与调用链（第 6–7 章）
| 节 | 文章 | 核心内容 |
|---|---|---|
| 6.1 | 限流算法与分布式限流 | 令牌桶、漏桶、滑动窗口、租约与误差 |
| 6.2 | 熔断状态机与恢复策略 | 关闭/打开/半开、阈值、半开探测与恢复 |
| 6.3 | 降级、兜底与用户体验 | 降级层级、兜底数据、提示语与退出条件 |
| 7.1 | 超时预算如何在调用链中分配 | 截止时间传播、剩余预算与跨层超时 |
| 7.2 | 重试放大与退避抖动 | 重试预算、指数退避、抖动与重试风暴 |
| 7.3 | 幂等键与去重窗口的实现与故障注入验证 | 幂等键存储、窗口、并发重复请求与故障注入 |
第四部分：拓扑、变更与观测（第 8–10 章）
| 节 | 文章 | 核心内容 |
|---|---|---|
| 8.1 | 冗余、故障域与单点消除 | 故障域划分、单点识别、冗余代价与切换单位 |
| 8.2 | 主备与故障转移：单区域高可用 | 主备模式、切换判据、脑裂防护与恢复 |
| 8.3 | 健康检查与流量摘除 | 存活/就绪、摘流顺序、在途请求与恢复探测 |
| 9.1 | 滚动、蓝绿与金丝雀 | 三种发布方式的代价、指标门槛与暂停条件 |
| 9.2 | 回滚、兼容窗口与数据迁移 | 向前/向后兼容、迁移顺序与回滚验证 |
| 9.3 | 开关与灰度的数据兼容约束 | 开关生命周期、灰度维度与数据双版本 |
| 10.1 | 订单链路的最小观测契约 | trace、日志、指标三类信号与字段约定 |
| 10.2 | 告警：从症状到行动的闭环 | 症状告警、阈值设计、行动手册与降噪 |
| 10.3 | 故障复盘与改进闭环 | 时间线、根因、改进项与可验证的关闭条件 |
第五部分：数据层与综合验收（第 11–13 章）
| 节 | 文章 | 核心内容 |
|---|---|---|
| 11.1 | 索引、查询与慢 SQL | 索引选择、执行计划、慢查询定位与改写 |
| 11.2 | 分页、批处理与连接管理 | 深分页改写、批量大小、连接池与超时 |
| 11.3 | 读写分离的延迟预算与一致性兜底 | 复制延迟、读己之写、强制主库与降级 |
| 12.1 | 压测基线与瓶颈分析 | 基线口径、pprof 结果与瓶颈排序 |
| 12.2 | 缓存、异步与限流改造 | 三项改造的落点、顺序与回退开关 |
| 12.3 | 改造前后同一口径的数字与失败注入结果 | 同场景对照、失败注入与结论边界 |
| 13.1 | 一次完整的容量规划 | 业务目标到实例数、余量与成本权衡 |
| 13.2 | 订单系统必测的三个故障场景 | 依赖变慢、实例丢失、缓存失效的观测与处置 |
| 13.3 | 进入卷三：分布式与一致性 | 卷二遗留假设、卷三问题清单与交接 |
与现有专题的关系
卷二与站内两个专题互补：
- 分布式系统 的 46 篇文章偏重协议、缓存中间件、消息队列与多活容灾。卷二只取单体内可验证的部分，跨节点问题留给卷三、卷四。
- 架构设计 的 47 篇文章偏重模式与决策背景。卷二在需要定义时用一段话概括并给出链接，不重复教程。
- 卷二新增的是 arch-lab 的治理组件：直方图、压测器、多级缓存、限流器、熔断状态机、重试策略、舱壁、健康检查、幂等中间件。它们按
// file:标记抽取后可独立编译。
读完卷二的标准
如果下面六件事都能独立完成，卷二的目标就达到了：
- 能设计一套延迟指标，说明每个分位数的口径、样本量和聚合方式。
- 能从业务指标算出峰值 QPS、并发数和实例数，并给出余量依据。
- 能判断一个场景该加缓存、改异步、加限流还是扩容量，并说明代价。
- 能写出带截止时间传播、重试预算和幂等的调用链。
- 能设计一次发布与回滚，说明兼容窗口和数据迁移顺序。
- 能组织一次故障演练，输出时间线、信号对比和改进项。
卷二结束时，arch-lab 是一个可压测、可限流、可熔断、可切换、可回滚的版本。卷三会在这个版本上追问：当数据分布在多个节点上，复制、共识、分区和事务又该怎么处理。
版本与反馈
| 组件 | 版本 |
|---|---|
| Go | 1.26.0 |
| Java | Temurin 21.0.13（LTS） |
| PostgreSQL | 18.4（L3 场景） |
| Redis | 7.x（可选，L3 场景） |
| Docker | 29.7.2 |
| Hugo | 0.163.3+extended |
代码块中的“实测”均来自本机 darwin/arm64 运行；未实际运行的数据库或多节点结论会标为“预期/需 L3/L4 验证”。发现错误时，请附完整命令、环境版本与原始输出，便于判断是代码、环境还是结论问题。