docs：《后端面试高频系统设计&场景题》介绍完善

Author: Snailclimb

docs/distributed-system/distributed-configuration-center.md

@@ -10,6 +10,8 @@ head:
       content: 配置中心,分布式配置中心,Apollo,Nacos,Spring Cloud Config,配置中心面试题,灰度发布,长轮询
 ---
 
+<!-- @include: @small-advertisement.snippet.md -->
+
 ## 为什么要用配置中心？
 
 微服务架构下，业务发展通常会导致服务数量增加，进而导致程序配置（服务地址、数据库参数、功能开关等）增多。传统配置文件方式存在以下问题：
@@ -25,7 +27,7 @@ head:
 - **版本管理**：记录每次配置变更的修改人、修改时间、修改内容，支持一键回滚。
 - **灰度发布**：先将配置推送给部分实例验证，降低变更风险（Apollo、Nacos 1.1.0+ 支持）。
 
-![view-release-history](https://oss.javaguide.cn/github/javaguide/config-center/view-release-history.png)
+![Applo 配置中心](https://oss.javaguide.cn/github/javaguide/config-center/view-release-history.png)
 
 ## 常见的配置中心有哪些？如何选择？
 

docs/distributed-system/protocol/cap-and-base-theorem.md

@@ -136,7 +136,7 @@ flowchart TB
 
 | 更贴近 CAP 讨论模型 | 需要拆分到分片/对象/操作级别分析     |
 | ------------------- | ------------------------------------ |
-| Redis 主从/哨兵集群 | 业务系统（无状态服务）\*             |
+| Redis 主从/哨兵集群 | 业务系统（无状态服务）               |
 | MySQL 主从/多主集群 | Redis-Cluster（每个 shard 仍有副本） |
 | MongoDB 副本集      | MongoDB-Cluster（分片 + 副本并存）   |
 | ZooKeeper、etcd     | 分库分表（跨分片事务需额外协调）     |
@@ -453,7 +453,7 @@ flowchart LR
 
 - **读时修复（Read Repair）**：在读取数据时，检测数据的不一致，进行修复。适合读多写少场景。
 - **写时修复（Hinted Handoff）**：在写入数据时，如果目标节点不可用，将数据缓存下来，待节点恢复后重传。**写时修复** 优化了写入延迟，但增加了读取时的不一致风险（数据可能还在缓存队列中未落盘到目标节点）。
-- **异步修复（Anti-Entropy/反熵）**：通过后台比对副本数据差异并修复。工程实现中关键挑战是**高效检测数据差异**——暴力逐条比对（O(n)）在大规模数据集下不可行，生产系统采用**默克尔树（Merkle Tree）**实现低开销差异定位：
+- **异步修复（Anti-Entropy/反熵）**：通过后台比对副本数据差异并修复。工程实现中关键挑战是**高效检测数据差异**——暴力逐条比对（O(n)）在大规模数据集下不可行，生产系统采用**默克尔树（Merkle Tree）**实现低开销差异定位。
 
 **选择建议**：
 
@@ -525,48 +525,4 @@ flowchart TB
 > - **BASE 的可用性** = 分片式集群的可用性（部分节点故障只影响部分用户）
 > - **CAP 与 BASE 的关系**：选择 AP 架构后，BASE 理论指导如何在工程实践中通过最终一致性达到系统收敛
 
-## 生产落地建议
-
-### 选择 CP 还是 AP 的决策框架
-
-> **重要提示**：简单给系统贴「CP/AP」标签是有风险的。在网络分区下：
->
-> - **X 的写更倾向于优先保持线性一致**（可能拒绝服务/降级）
-> - **Y 更倾向于优先保持可用**（允许短时间读到旧数据）
->   具体取决于操作类型与配置。
-
-| 场景特征                       | 倾向选择       | 典型系统说明                                                |
-| ------------------------------ | -------------- | ----------------------------------------------------------- |
-| 强一致性要求（金融转账）       | 倾向线性一致写 | ZooKeeper（写入需 Quorum 确认）、etcd、Consul（CP 模式）    |
-| 高可用优先（服务发现）         | 倾向可用性     | Eureka（允许读到旧实例）、Consul（可切换模式）              |
-| 可调一致性（根据业务动态选择） | 可配置         | Nacos（支持 CP/AP 切换）、Cassandra（可调节读写一致性级别） |
-| 写多读少                       | 倾向异步写优化 | Cassandra（可配置 QUORUM 写）、HBase                        |
-| 读多写少                       | 倾向低延迟读   | DynamoDB（可调节最终一致性级别）                            |
-
-### 监控指标
-
-- **分区检测时间**：多久发现网络分区
-- **收敛时间（Convergence Time）**：副本从不一致到一致的时间
-- **读写延迟 P99**：CAP 权衡的直接体现
-- **不一致窗口**：业务可接受的数据延迟
-
-### 常见误区
-
-#### CAP 相关误区
-
-- ❌ 「选择了 AP 就永远放弃一致性」→ ✅ AP 系统可通过 Read Repair、Anti-Entropy（Merkle Tree）达到最终一致
-- ❌ 「ZooKeeper 是强一致的」→ ✅ ZooKeeper 提供**线性化写入** + **顺序一致性读取**（非最终一致性），读取存在滞后但保证全局顺序
-- ❌ 「顺序一致性 = 最终一致性」→ ✅ 顺序一致性保证全局更新顺序，最终一致性不保证顺序；ZooKeeper 普通读取是前者而非后者
-- ❌ 「银行系统必须 CP」→ ✅ 实际银行采用 BASE + 补偿事务（Saga），核心账务强一致，查询服务可最终一致
-- ❌ 「业务系统不需要考虑 CAP」→ ✅ 业务系统虽不直接实践 CAP，但 RPC 路由、限流熔断、分布式锁等均受底层组件 CAP 属性影响，忽视会导致级联雪崩
-- ❌ 「分库分表不需要考虑 CAP」→ ✅ 分片式存储通常仍然需要为每个 shard 做副本复制，因此仍需面对 CAP 的权衡
-- ❌ 「CAP 的 A 等于低延迟/高 SLA」→ ✅ CAP 的可用性定义不包含延迟要求，只要求非故障节点必须返回响应（可以很慢）
-
-#### BASE 相关误区
-
-- ❌ 「BASE 是 CAP 的补充/延伸」→ ✅ BASE 首先是 ACID 的替代品；同时 BASE 是 AP 架构的工程实践指南（AP 选择了放弃强一致性，BASE 告诉你如何达到最终一致）
-- ❌ 「BASE 的一致性 = CAP 的一致性」→ ✅ BASE 的一致性是状态一致性（= ACID 一致性），CAP 的一致性是数据一致性
-- ❌ 「BASE 只适用于主从集群」→ ✅ BASE 适用于所有分布式系统；其「基本可用」概念在分片式集群中表现更明显（部分节点故障只影响部分用户）
-- ❌ 「最终一致性是弱一致性」→ ✅ 最终一致性是弱一致性的升级版，保证系统最终会达到一致状态，而弱一致性不提供此保证
-
 <!-- @include: @article-footer.snippet.md -->

docs/distributed-system/protocol/consistent-hashing.md

@@ -115,7 +115,7 @@ hash（服务器ip）% 2^32
 
 如下图所示，Node1、Node2、Node3、Node4 这 4 个节点都对应 3 个虚拟节点（下图只是为了演示，实际情况节点分布不会这么有规律）。
 
-![](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/consistent-hashing/consistent-hashing-circle-virtual-node.png)
+![虚拟节点](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/consistent-hashing/consistent-hashing-circle-virtual-node.png)
 
 对于上图来说，每个节点最终负责的数据情况如下：
 

docs/distributed-system/protocol/paxos-algorithm.md

@@ -62,7 +62,7 @@ Basic Paxos 中存在 3 个重要的角色：
 2. **接受者（Acceptor）**：也可以叫做投票员（voter），负责对提案进行投票，同时需要记住自己的投票历史。
 3. **学习者（Learner）**：负责学习（learn）已被选定的值。在复制状态机（RSM）实现中，该值通常对应一条待执行的命令，由状态机按序 apply 后再由对外服务层返回结果。
 
-![](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/up-890fa3212e8bf72886a595a34654918486c.png)
+![Basic Paxos中的角色](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/up-890fa3212e8bf72886a595a34654918486c.png)
 
 **角色交互关系图**：
 

docs/high-performance/cdn.md

@@ -8,6 +8,8 @@ head:
       content: CDN,内容分发网络,GSLB,CDN缓存,CDN回源,CDN预热,防盗链,时间戳防盗链,静态资源加速
 ---
 
+<!-- @include: @small-advertisement.snippet.md -->
+
 ## 什么是 CDN ？
 
 **CDN** 全称是 Content Delivery Network/Content Distribution Network，翻译过的意思是 **内容分发网络** 。

docs/high-performance/data-cold-hot-separation.md

@@ -8,6 +8,8 @@ head:
       content: 数据冷热分离,冷数据迁移,冷数据存储,分层存储,TiDB冷热分离,HBase,数据归档,存储成本优化
 ---
 
+<!-- @include: @small-advertisement.snippet.md -->
+
 ## 什么是数据冷热分离？
 
 数据冷热分离是指根据数据的**访问频率**和**业务重要性**，将数据划分为冷数据和热数据，并分别存储在不同性能和成本的存储介质中的架构策略。

docs/high-performance/deep-pagination-optimization.md

@@ -8,6 +8,8 @@ head:
       content: 深度分页,分页优化,LIMIT优化,MySQL分页,延迟关联,覆盖索引,游标分页
 ---
 
+<!-- @include: @small-advertisement.snippet.md -->
+
 ## 深度分页介绍
 
 查询偏移量过大的场景我们称为深度分页，这会导致查询性能较低，例如：

docs/high-performance/load-balancing.md

@@ -8,6 +8,8 @@ head:
       content: 负载均衡,四层负载均衡,七层负载均衡,Nginx负载均衡,LVS,负载均衡算法,轮询,一致性哈希,客户端负载均衡
 ---
 
+<!-- @include: @small-advertisement.snippet.md -->
+
 ## 什么是负载均衡？
 
 **负载均衡** 指的是将用户请求分摊到不同的服务器上处理，以提高系统整体的并发处理能力以及可靠性。负载均衡服务可以有由专门的软件或者硬件来完成，一般情况下，硬件的性能更好，软件的价格更便宜（后文会详细介绍到）。

docs/high-performance/read-and-write-separation-and-library-subtable.md

@@ -8,6 +8,8 @@ head:
       content: 读写分离,分库分表,主从复制,水平分表,垂直分库,ShardingSphere,MyCat,分布式ID,跨库查询
 ---
 
+<!-- @include: @small-advertisement.snippet.md -->
+
 ## 读写分离
 
 ### 什么是读写分离？

docs/high-performance/sql-optimization.md

@@ -8,6 +8,8 @@ head:
       content: SQL优化,慢SQL,EXPLAIN执行计划,索引优化,MySQL优化,查询优化,分页优化,Show Profile
 ---
 
+<!-- @include: @small-advertisement.snippet.md -->
+
 ## 避免使用 SELECT \*
 
 - `SELECT *` 会消耗更多的 CPU。