为什么我不建议你阅读《数据密集型应用系统设计》（之三）

分布式存储系统的常见挑战

“不可靠”的数据复制

在上一篇文章中，我们讨论了数据的复制机制。在理想情况下，副本间的数据同步通常能在毫秒级内完成（跨地域时可能达到百毫秒级）。但实际环境远不总是理想的。由于网络抖动、链路中断、节点重启等因素，数据复制在某些情况下会出现秒级甚至分钟级的延迟；如果遇到节点长时间下线，更可能出现数据副本严重不一致的情况。

这对复制协议提出了巨大的挑战：

如果采用同步复制协议，即每条写入都要求所有副本成功确认后才能返回成功，那么只要有一个副本故障或延迟，整个写入流程就会阻塞，严重影响系统可用性；
如果采用异步复制协议，虽然可以提升可用性和写入吞吐量，但容易出现副本间状态不一致的情况。一些“快副本”已经处理完最新写入，而“慢副本”可能仍滞留在较旧的版本，导致相同的读请求在不同副本上返回不同结果，这种行为是反直觉的。

这类副本不一致的问题，通常需要借助 版本号、向量时钟、或者合并策略来解决。但在用户可见的数据上，这类差异往往会被感知为“数据不稳定”或“系统不可靠”，尤其在多地部署、跨区域访问的系统中尤为显著。

“不可靠”的时钟

在分布式系统中，时钟同步是一个长期未解的“老问题”。这是因为每台机器的硬件时钟本身就存在漂移，而借助网络同步协议（如 NTP）也会不可避免地引入延迟抖动与误差上限。虽然可以通过部署 GPS、原子钟等硬件来获取更高精度的时钟，但这会显著提高运维成本，也并不适用于所有场景。

时间不可靠，会直接影响到基于时间戳的操作决策 —— 比如选择最新版本的数据、判断操作先后顺序、设定超时等。

为了绕开对物理时间的强依赖，分布式系统通常会引入以下两种方案：

单调逻辑时钟（如 Lamport Clock）：不依赖真实时间，仅保证“事件先后”的单调性，即后来的事件时间戳总大于前一个。这在因果性判断中非常有用。
混合时钟（如 Hybrid Logical Clock）：结合物理时间和逻辑时钟，在尽量保留实际时间语义的同时，兼顾可比性和单调性，是一些新型分布式数据库（如 CockroachDB）所采用的策略。

此外，也有像 Google Spanner 那样的系统使用了更激进的手段 —— 它基于 GPS 和原子钟构建了一个全局“置信时钟窗口”（TrueTime），允许系统在已知的最大时钟误差范围内进行一致性推理。这虽然代价较高，但在需要严格全球一致性的场景中是当前最实用的路径之一。

分布式事务

在分布式数据系统中，最典型的应用场景是键值存储。对于这类系统，单次读写往往就是一个完整的业务操作。系统的可靠性此时主要依赖副本机制来保障：在多数情况下，只要数据成功写入任意副本（或写入达成多数派确认），系统即可对外返回成功，后续的副本同步则交由后台异步处理。

然而，随着业务复杂性提升，单点读写已不足以覆盖所有逻辑。此时，我们需要将多个相关的读写操作打包为一个原子性的操作单元 —— 这正是事务产生的背景。

事务的核心目标非常明确：要么全部成功，要么全部失败。这大大降低了开发者的心智负担 —— 无需再为中间状态的异常处理编写大量补偿逻辑，系统也能避免因“部分提交”造成的数据污染。

分布式事务的 ACID 与 BASE

传统数据库中的事务遵循 ACID 原则：

A（Atomicity，原子性）：事务中的所有操作必须全部完成，或全部不做；
C（Consistency，一致性）：事务完成后，系统从一个一致状态转变到另一个一致状态；
I（Isolation，隔离性）：并发执行的事务互不干扰；
D（Durability，持久性）：一旦提交的数据不能丢失，即使系统崩溃。

然而在分布式环境下，严格遵守 ACID 通常意味着高延迟、复杂的锁管理，以及对网络中断的极度敏感。在追求高可用、横向扩展、低延迟的背景下，许多系统转而采用更宽松的 BASE 理论：

Basically Available（基本可用）：系统即使出现故障，也尽量保持部分功能可用；
Soft State（软状态）：系统状态在一段时间内允许不一致；
Eventual Consistency（最终一致性）：只要不发生新的更新，所有副本最终会趋于一致。

BASE 并不是 ACID 的“反面”，而是为了解决分布式条件下“网络不可靠”“节点不可用”“复制延迟”等问题所做的一种实用妥协。ACID 更强调一致性和正确性，BASE 更强调可用性和恢复能力。

事务隔离级别：性能与一致性的权衡

在支持事务的分布式系统中，另一个核心挑战是如何处理并发读写引发的数据冲突。这决定了系统提供的隔离级别（Isolation Level）。

理想状态下，我们希望事务之间完全串行执行 —— 没有任何交叉。但这会带来严重的性能瓶颈。因此系统通常设计多个隔离等级，提供不同程度的并发控制：

读已提交（Read Committed）
每个事务只能读取到其他事务“已提交”的数据。这避免了脏读，但仍可能出现“不可重复读”（同一条记录先后读取结果不同）。
快照隔离（Snapshot Isolation）
每个事务在开始时看到的是数据库的某一时刻快照。虽然可避免脏读和不可重复读，但无法防止 写倾斜（Write Skew） —— 多个事务读取相同状态后独立写入，结果违反了业务约束。
可重复读（Repeatable Read）
每次读取相同记录得到的值不变，但对于范围查询仍可能遇到 幻读（Phantom Read） —— 第二次查询返回了新插入或删除的行。
串行化（Serializable）
最强隔离等级，要求事务执行效果等同于串行执行。能彻底消除幻读、写倾斜等问题，但开销也最大。常见实现方式有：
基于锁的两阶段锁协议（2PL），强制事务在获取锁后完成或回滚；
基于版本控制和冲突检测的 SSI（Serializable Snapshot Isolation），通过检测事务之间的读写依赖关系，在提交时回滚冲突事务。

这一系列隔离等级背后，其实是一致性、并发性与可用性三者之间的动态权衡。系统必须根据业务特点和性能要求，选取合适的隔离级别。

小结

分布式存储系统并不只是“多放几份数据”这么简单。它必须在不可靠的网络、失效的节点、漂移的时钟和冲突的写入之间，构建起一个对用户“看起来稳定可靠”的系统。而这背后，是副本同步机制、时钟模型、事务协议与一致性等级等一系列工程权衡与设计抉择。

我们无法一劳永逸地解决所有问题，只能根据具体场景选择合适的折中方案。正如你所看到的：CAP 不可兼得，ACID 与 BASE 各有利弊，串行化隔离并非银弹 —— 分布式系统的设计，从来都是一场关于“权衡”的艺术。

在接下来的文章中，我们将继续探索分布式系统中，一致性定义、常见一致性模型的适用场景 —— 如果有下一篇的话。