第3章 通用内功：分布式设计通行法则
第3章 通用内功：分布式设计通行法则
本章要回答的三个问题：为什么分布式数据库必须在一致性、可用性、分区容错之间做选择？"最终一致"到底给业务承诺了什么、没承诺什么？当单条业务规则要跨多个数据单元时，NoSQL 世界怎么保证正确性？
为什么会有这一章
第 2 章拜访五大门派时反复出现几个词：复制、分片、AP 或 CP、最终一致。当时刻意按下不表，因为它们不属于任何单一门派，而属于所有门派共同的底层——分布式系统。数据一旦摊到多台机器，网络就会延迟、断开、乱序，节点的钟就会不同步，任何"看起来理所当然"的单机假设都可能崩塌。
这一章修炼的内功直接决定你能否读懂第 4、5 章的机制设计：MongoDB 的复制集为什么这样选举、写关注为什么那样配置，Redis 哨兵为什么有脑裂防御参数，全部是本章法则的具体应用。反过来，跳过本章直接背产品配置，你记住的只是一堆没有因果的参数名。
读完能解决什么
读完本章你应当能够：用 CAP 定理与 PACELC 分析任一存储产品的分布式行为；在业务设计里正确使用 BASE 与各档一致性级别，明确"读己之写""单调读"这些保证由谁提供；识别分布式事务的几种实现（两阶段提交、TCC、Saga）与各自的故障面；用非范式化与查询优先的方式做 NoSQL 建模；并为一个增长的系统设计分片方案，评估热点与再平衡代价。
各节怎么分工
| 节号 | 回答哪个问题 | 关键产出 |
|---|---|---|
| 3.1 | 分布式的根本约束是什么 | CAP 三角 + PACELC 推广 |
| 3.2 | 放弃强一致换到什么 | BASE 三要素与 ACID 对照 |
| 3.3 | 一致性有哪些档位 | 从线性一致到最终一致的阶梯 |
| 3.4 | 跨节点业务规则怎么保证 | 2PC、TCC、Saga 与幂等 |
| 3.5 | 数据该怎么组织 | 非范式化与查询优先建模 |
| 3.6 | 规模怎么变成加法 | 三种分片策略与再平衡 |
前三节是理论阶梯：3.1 给出不可逾越的约束，3.2 给出约束之下的实用哲学，3.3 把哲学细化为可操作的档位。后三节转向工程：3.4 处理跨单元一致性，3.5 与 3.6 分别处理建模与扩展这两个 NoSQL 设计的日常功课。
先决条件
需要第 1 章的扩展方式概念（垂直与水平）与第 2 章的门派常识。数学与证明细节不需要——本章讲的是工程含义，不是形式化验证。
内功与门派的对应关系
这一章的概念看起来抽象，但它们都会在后面两章以具体形态出现。建立这层对应关系，读第 4、5 章时会顺畅很多。
| 本章内功 | 在 MongoDB 中的形态 | 在 Redis 中的形态 |
|---|---|---|
| CAP 取舍（3.1） | 写关注与读关注档位：多数确认即保 C | 异步复制 + 可选 WAIT 命令：默认保 A |
| BASE 与收敛（3.2） | 复制集的 oplog 回放 | 主从复制的增量同步与部分重同步 |
| 一致性档位（3.3） | readConcern 的 local / majority / snapshot | 读写分离下默认最终一致 |
| 分布式事务（3.4） | 4.0 起的多文档 ACID 事务 | MULTI/EXEC 与 Lua 脚本（单节点原子） |
| 非范式化建模（3.5） | 嵌入 vs 引用（4.2 展开） | 数据结构按访问模式选型（5.2） |
| 水平扩展（3.6） | 分片集群的区间分片与 chunk 迁移 | Cluster 的固定 16384 槽位 |
本章的三个台阶
第一阶，能选：拿到业务需求，能说出一致性档位怎么定、分片键候选是什么、哪些数据可以接受最终一致。
第二阶，能算：能估算不一致窗口的时长、再平衡要搬多少数据、跨片查询会放大多少倍代价。这一阶要求把概念换成数字，是"懂"与"会用"的分界。
第三阶，能排错：遇到"读到旧数据""迁移卡住""节点数增加但性能不升"时，能顺着本章的概念定位到根因。这一阶只能在生产事故里练出来，但有了前面两阶的铺垫，排错时至少知道该往哪个方向查。
学习顺序建议：3.1 到 3.3 是"世界观"，要连着读；3.4 到 3.6 是"手艺"，可以边读边在本地动手试。
往下走到哪
本章结束时，你应能带着"约束 — 哲学 — 档位 — 事务 — 建模 — 分片"这套完整框架进入第 4 章：MongoDB 复制集与分片就是 3.1 与 3.6 的产品化实例，它的事务支持是 3.4 中两阶段提交思想在文档模型上的落地。第 5 章的 Redis 哨兵与集群同理。理论章读完就应在产品章里找实例，否则会忘。