第2章 一致性的天平

第2章 一致性的天平

本章跟着一条线走：分布式把数据复制成多份之后，立刻要知道"多份之间能不能说读到一份就一样"——这就是一致性。这一章给一致性装上两把尺子：CAP 定理告诉你哪些目标注定不能同享，一致性模型告诉你"差异"可以被约定成多少种可接受的形态。整章是一条从"无奈的选择"走向"有选择的设计"的线。

本章路线图

一条主线

第 1 章你接受了"网络不可靠、故障会来"。现在数据成了多份，麻烦立刻变具体：客户端写了一次，等它再读时，到底读到哪一份？这一章的主线，是围绕着一张表展开的——数据放了三份，任何一个节点出问题，你都必须在"响应快但可能给旧值"和"一定给新值但可能要堵住等"之间做选择。我们把这枚硬币的两个面分别叫一致性 C 和可用性 A。点破"你没法两个都拿到"的，就是 CAP 定理；告诉你"拿不到强一致时还能拿什么别的"的，是 BASE 与一致性模型。

沿途站点

• 2.1 CAP 定理：C 一致性、A 可用性、P 分区容忍性，三者最多保两个。主线推进到：承认取舍是宿命，P 是必选题。
• 2.2 BASE 与 ACID 的此消彼长：把"最终一致性"这条妥协路线讲清楚，和单机的 ACID 对照着看。主线推进到：主动牺牲一部分强一致、换取可用与性能。
• 2.3 数据分布策略：数据被按哈希、范围、列表切成块。主线推进到：一致性的取舍要落在"切到哪一块"上才有意义。
• 2.4 复制与一致性模型：从强一致、因果一致到最终一致的分级体系，以及复制方式如何决定你能提供哪一级。主线推进到：从"被迫做选择"升级为"有目的地设计一致性的档位"。

拐点与结论

这一章最关键的认知转折是：一致性不是"有或无"，而是一根可以分档的刻度尺。新手眼里只有"强一致"和"脏读"两个极端；学完本章你会发现强一致、顺序一致、因果一致、最终一致是连续的档位，每退一档，就换到一定的性能与可用性余量。判断一个系统好不好，不是看它是不是强一致，而是看它有没有把"客户其实只需要哪一档一致"这问题想清楚。

读完你应该

1. 用 CAP 定理解释为什么"既强一致又保持高可用"在网络分区时做不到。
2. 陈述"最终一致"的核心思想，并说清它与 ACID 的一处关键不同。
3. 比较哈希、范围、列表三种分片方式的数据分布特点与热点风险。
4. 区分强、顺序、因果、最终一致四级，举出各自适合的业务场景。
5. 说明复制拓扑（主从、多主、链式）如何决定你能提供的一致性档位。

一张四档贴纸：先想清楚客户要哪档

学完本章你手里会多一张四档贴纸，常把它贴在手边：强一致——读到的必是最新值，适合账务、库存扣减这类"错一个子都不行"；顺序一致——单客户看到自己的操作按顺序发生，适合个人会话与订单状态流；因果一致——有因果关系的写操作按序可见，别的顺延即可，适合社交时间线；最终一致——短暂读到旧值但总会追平，适合点赞数、阅读量等对实时性不敏感的数据。真正的问题从来不是"这系统强一致吗"，而是"我这条业务到底需要第几档、愿意为它付出多大延迟代价"。带着这张贴纸去读后面每一章，你会立刻明白为什么 TiDB 敢叫强一致、而 Cassandra 只承诺最终一致。

下一章的接力

一致性是"逻辑层面怎么约定"，但约定要落地，必须看"物理上节点怎么被组织"——这正是第 3 章架构要回答的：Shared-Nothing、Shared-Disk、Shared-Memory 三种组织方式，决定了你在 2.1 里做的取舍能否真的兑现。第 3 章把第 2 章的尺子装进真实集群。