分布式系统不是“多台机器一定更快”，而是数据跨进程后必须面对消息延迟、丢失、乱序和节点故障。本篇给你一套判断语言：先确认故障模型，再讨论一致性，不用一句“CAP 只能三选二”结束设计。
Table of contents
Open Table of contents
CAP 到底约束什么
假设订单写入节点 A，查询发到节点 B。网络分区（Partition）指节点仍在运行但彼此暂时无法通信。此时系统只能在两种行为间选择：拒绝一部分请求以保住一致结果，或继续响应但允许读到旧值。
| 字母 | 含义 | 可验证的问题 |
|---|---|---|
| C | 一致性，CAP 语境下接近线性一致 | 成功写入后，后续读取是否都看见它 |
| A | 可用性 | 每个非故障节点能否在有限时间响应 |
| P | 分区容错 | 节点间丢包时系统能否继续工作 |
真实跨网络系统无法选择“不要 P”。设计决策是分区发生时偏向 C 还是 A，而且不同操作可以不同：付款扣款偏 C，商品评论读取可偏 A。
PACELC 补上正常时期
PACELC 表示：发生分区时在可用性与一致性间选择（PA/PC）；没有分区时，还要在延迟与一致性间选择（EL/EC）。同步等待多个副本通常得到更强一致性，也增加尾延迟。
一致性还分层次：
- 线性一致：每次操作像在真实时间中的某一点瞬间完成。
- 顺序一致：所有客户端看到同一操作顺序，但不承诺符合墙上时钟。
- 最终一致：停止更新后，副本最终收敛；它没承诺多久收敛。
- 业务一致：业务不变量成立，例如余额不为负；它不是严格的学术一致性级别。
把口号改成验收条件
不要写“订单系统要求强一致”。写成：支付成功响应后 1 秒内，任意查询不得返回“未支付”；网络分区时支付请求失败关闭，商品详情允许返回不超过 5 分钟的缓存。这样才能设计测试与告警。
法定人数（Quorum）是超过半数的确认集合。打开分布式系统实验室下载，运行：
mvn -Dtest=DistributedMechanismsTest#snowflakeIdsIncreaseAndQuorumRequiresMajority test测试展示 5 个成员至少需要 3 个确认；任意两个多数派必然相交，但“多数派”本身不等于完整共识协议。
下一步
继续阅读08-02 超时、重试、幂等、去重与退避，把故障模型落实到每一次远程调用。