一致性

本文是摘取了一些Werner Vogels关于最终一致性博客内容进行翻译，并在有些地方重新组织，加上了自己理解。

一致性问题的历史发展

完美的一致性模型是：当做了一个更新操作，所有的观察者将看到这个更新。
在70年代后期的数据库系统，这个完美的一致性模型第一次被认为很难达到。
在90年代中期，随着更大规模的互联网系统的出现，许多之前的实践被修正。人们开始思考有效性可能不是系统最重要的特性，同时他们在努力寻找什么应该被权衡考虑。
在2000年 Principles of Distributed Computing大会上Eric Brewer发表了CAP理论。CAP理论：共享数据系统的三个特性-数据一致性、系统有效性、分区容忍性- 在任何给定时间，只能有其中两个能够达到。
在2002年, Seth Gilbert和Nancy Lynch发表了更加正式的CAP理论论证。

CAP理论的讨论：

Data Consistency（数据一致性）	System Availibility(系统有效性）	Tolerance to network partition（分区容忍性)	说明
		不满足	在事务协议中，客户端和存储系统必须在相同的环境中。在某些场景中，他们会为一个整体失败。正是这样，客户端不能观察多个分区。
		满足	在大规模的分布式系统，需要实现网络分区，因此一致性和有效性不能同时达到。要么牺牲一致性，获得高有效性；要么牺牲有效性，获得一致性。客户端开发人员需要意识到系统是哪一种选择。
满足	不满足	满足	如果系统强调一致性，开发人员需要处理系统无效的情况。例如，写操作。如果因为系统无效导致写失败，那么开发者将需要处理那些需要被写入的数据
不满足	满足	满足	如果系统强调有效性，它可能会总是接收写操作，但是在有些条件下，读操作将不能返回最近写操作的结果。开发人员需要决定客户端是否总是需要访问最近的更新。

有两种衡量一致性的方式:

强一致性：在更新操作完成之后，任何后续的访问将返回更新的值。
弱一致性：系统不能保证后续访问返回更新的值。需要在一些条件满足之后，更新的值才能返回。从更新操作开始，到系统保证任何观察者总是看到更新的值的这期间被称为不一致窗口。
最终一致性：这是弱一致性的特殊形式；存储系统保证如果没有对某个对象的新更新操作，最终所有的访问将返回这个对象的最后更新的值。

最终一致性模型有如下对考虑者很重要的变种。在基本的最终一致性模型规则上加上了一些额外的规定。

因果一致性：如果进程A通知进程B它已经更新了一个数据项，那么进程B的后续访问将返回更新后的值，并且写操作将被保证取代前一次写入。和进程A没有因果关系的C的访问将遵循正常的最终一致性规则。
读己之所写一致性：这是一个重要的模型。进程A更新了一个数据项之后，总是访问到更新后的值而不会看到旧值。这是因果一致性模型的一个特例。
会话一致性：这是上一个模型的实用版本。进程在一个会话上下文中访问存储系统。只要会话存在，系统保证读己之所写一致性。如果会话由于某个失败场景而终止，一个新的会话需要被创建，并且保证不和之前会话重叠。
单调读一致性：如果一个进程已经看到某个对象的一个特定的值，那么任何后续的访问将不会返回任何先前的值。
单调写一致性：系统保证在同一个进程中串行化写操作。不能保证这种一致性级别的系统是众所周知地难以编程。

这些属性可以组合起来。例如，单调读和会话一致性可以组合在一起。

在服务器端，我们需要更加深入地分析更新是如何流经系统，并由此来理解什么驱动了不同模式。这些模式正是系统的开发者能够体验到的。让我们先作如下定义。

N=存储数据副本的结点数量 W=在更新完成之前，需要同时认可接收的副本数量 R=当读操作访问数据对象，需要访问的副本数量

如果W+R>N, 那么写集合和读集合总是重叠并且能保证强一致性。如在主备RDBMS中，如果使用了同步副本的方式，N=2，W=2和R=1。不管客户端读哪个副本，它总是获得一致性结果。
如果W+R<=N, 那么不能保证强一致性，只能是弱一致性或最终一致性。如在主备RDBMS中，使用异步同步副本，并开启从副本读功能的方式，那么N=2, W=1和R=1。在这种情况下，R+W=N, 一致性不能得到保证。