一致性与可用性：Werner Vogels 谈最终一致性

直到 90 年代中期，当谈到数据复制的时候，分布的透明性和数据的一致性常常都是重要的工作目标。随着大型 Internet 系统开始崛起，可用性（availability）也成了另一项重要的考虑因素。 Eric Brewer 提出的 CAP 定理说，“在数据共享的系统的三项属性当中，数据一致性、系统可用性和对网络分区的耐受性，在任何给定时间内都只能达成其中的两项”。由于“在较大分布规模的系统中，网络分区是给定的”，因此一致性和可用性必有一项需要放宽。

在此前提下，最终一致性（eventual consistency）的概念开始赢得关注。与他在 QCon London 2007 上的演讲一脉相承，Werner Vogels 最近在博客上总结了一些与大规模数据复制及一致性需求相关的原则、抽象和权衡。

他强调说一致性并不是绝对优先考虑的事：

不一致是可以容忍的，这有两个理由：一是可以在高并发条件下提高读写性能；二是处理一些分区状况——多数决模型（majority model）有可能使系统的一部分表现为不可用，虽然那些节点正运行良好。

不一致是否可接受取决于客户应用程序。Vogels 给出了一个网站的例子，例中真正重要的是“用户感知到的一致性”，也就是让不一致窗口——即“更新发生时刻到任何观察者都一定能观察到更新后数据的时刻之间的时间段”——“小于顾客对下一页面加载时间的期待”，这样更新就可在预期发生下一次读取的时刻之前传播到整个系统。

如果换成更浅显的语言，Vogels 说，“看待一致性有两种角度”：

一种是从开发者 / 客户端的角度；他们如何观察数据更新。第二种是从服务器的角度；更新如何流经整个系统，系统对更新有何保证。

在客户端，Vogels 列举了四个角色：一个被观察者看作是“黑盒”的存储系统，而观察者由三个进程来扮演：“进程 A[……] 对存储系统进行读写”，“进程 B 和进程 C[……] 独立于进程 A，它们也读写存储系统”。这些进程是“独立的，并且需要相互通信以共享信息。”客户端一致性就在于“一个观察者（在此即进程 A、B 或 C）如何以及何时看到存储系统中的一个数据对象被更新。”

一致性有不同程度：

• 强一致性。在更新完成后，（A、B 或 C 进行的）任何后续访问都将返回更新过的值。
• 弱一致性。系统不保证后续访问将返回更新过的值，在那之前要先满足若干条件。通常条件就是经过一段时间，也就是不一致窗口。
• 最终一致性。存储系统保证如果对象没有新的更新，最终（在不一致窗口关闭之后）所有访问都将返回最后更新的值。

Vogels 还概要说明了最终一致性模型的各种变体：

• 因果一致性。如果进程 A 通知进程 B 它已更新了一个数据项，那么进程 B 的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程 A 无因果关系的进程 C 的访问遵守一般的最终一致性规则。
• “读己之所写（read-your-writes）”一致性。这是一个重要的模型。当进程 A 自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。
• 会话（Session）一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。
• 单调（Monotonic）读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
• 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

在服务器端，关注的是如何达到一致性和可用性的程度要求。Vogels 举出了各种场景，其中“N 是保存数据副本的节点数量，W 是在更新完成之前需要确认收到更新的副本数量，R 是当通过一次读操作访问一个数据对象时要联系的副本数量”。

如果 W+R > N，那么写集合与读结合总是重叠的，那么我们可以保证强一致性。[……] 这种遵循简单的法定人数规则（basic quorum protocols）的安排方法，其问题是当系统由于某种失败而不能写入到 W 个节点时，写操作就必须失败，使系统不可用。

[…]

当 R=1 且 N=W，对读操作是最优的。当 W=1 且 R=N，这样的优化可以得到非常快速的写操作。当然在后一例中，要是存在失败就保证不了了；而且如果 W < (N+1)/2 有可能出现写冲突，因为写集合没有重叠。

当 W+R <= N 就会出现弱一致性 / 最终一致性，即读集合与写集合没有重叠。如果故意要这么安排，又不是出于某种失败情形的考虑，那么只有把 R 设为 1 才是合理的。

[…]

如果 W+R <= N，那么系统就存在缺陷，有可能从未收到更新的节点读取数据。

“读己之所写”一致性、会话一致性和单调一致性是否可以达成，取决于客户端对为其执行分布式协议的服务器的“粘度”。如果每次都是同一台服务器，那么就比较容易保证“读己之所写”一致性和单调一致性。这样做会使管理负载平衡以及容错变得稍困难一些，但这是一种简单的方案。使用会话可使意图更加明确，且为客户端提供了适当的推理基础。

查看英文原文： Consistency vs. availability: eventual consistency by Werner Vogels