最终一致性

Eventually Consistent – Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.

可以从两个角度看待一致性。一个是从开发者、客户端的角度：它们如何观察数据更新。第二种是从服务器端看待：更新如何流通整个系统且系统对更新有什么保证。

客户端一致性：

客户端需考虑一下部分：

存储系统 它在本质上是大规模且高度分布的系统，其创建目的是为了保证耐用性和可用性。 进程A 对存储系统进行读写。 进程B和C 这两个进程完全独立于进程A，也读写存储系统。无论B、C是真正的进程还是进程内的现场，它们是相对独立的。B、C需要通信以分享信息。客户端一致性必须处理一个观察者（在此即进程A、B或C）如何以及何时看到存储系统中的一个数据对象被更新。 强一致性 在更新完成后，（A、B或C进行的）任何后续访问都将返回更新过的值。 弱一致性 系统不保证后续访问将返回更新过的值，在那之前要先满足若干条件。从更新到保证任一观察者看到更新值的时刻之间的这段时间被称为不一致窗口。 最终一致性。这是弱一致性的一种特殊形式；存储系统保证如果对象没有新的更新，最终所有访问都将返回最后更新的值。如果没有发生故障，不一致窗口的最大值可以根据下列因素确定：比如通信延迟、系统负载、复制方案涉及的副本数量。DNS是实现最终一致性的最流行的系统。

客户端一致性模型的变体有：

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

几个定义：

N = the number of nodes that store replicas of the data

W = the [...]