数据库系统内幕

214

｜

第

12

章

未包含所有写入。

读修复可以实现为

阻塞

或

异步

操作。阻塞读修复中，原始的客户端请求必须等到协调者

“修复”副本才能返回。而异步读修复仅仅只是调度一个修复任务，读请求的结果可以

立即返回给用户。

对于 Quorum 读来说，

阻塞

读修复能确保读取的单调性（参见 11.6 节）：一旦客户端读取

到某个值之后，后续的读请求要么返回一样的值，要么返回更新的值，因为副本状态已

经修复了。如果不使用 Quorum 读，则会失去这一单调性保证，因为在后续读取时数据

可能尚未传播到目标节点。与此同时，阻塞读修复会牺牲可用性，因为修复需要由目标

副本确认，并且只有当它们响应后才能返回。

为了准确检测出各副本响应的记录之间的差异，一些数据库（例如 Apache Cassandra）

使用了具有合并监听器（merge listener）的专用迭代器，它能重新构建出合并后的结果

与各个输入之间的差异。之后，协调者将这些差异通知副本，告知它们缺失的数据。

读修复假定副本

大多数情况下

是同步的，我们不希望每个请求都回退到阻塞修复。由于

阻塞修复的读取单调性，只要中间没有发生写操作，我们可以期望后续请求返回相同且

一致的结果。

12.2

摘要读

协调者也可以不向每个节点都发出完全读取请求，而是只发一个完全读取请求，而向

其他副本仅仅请求数据的

摘要

（digest）。摘要请求读取副本本地数据

—

不是完整的

数据快照，而是计算出数据的哈希值。之后，协调者可以算出完整读取的哈希值，并

将其与所有其他节点返回的摘要进行比较。如果所有摘要都匹配，则可以确信各个副 ...