分布式系统一致性

参考：

• 【1】Thomas R H. A majority consensus approach to concurrency control for multiple copy databases[J]. ACM Transactions on Database Systems (TODS), 1979, 4(2): 180-209.
• 【2】Bermbach D. Benchmarking eventually consistent distributed storage systems[M]. KIT Scientific Publishing, 2014.
• 【3】Özsu M T, Valduriez P. Principles of distributed database systems[M]. Springer Science & Business Media, 2011.
• 【4】Vogels W. Eventually consistent[J]. Communications of the ACM, 2009, 52(1): 40-44.
• 【5】Saito Y, Shapiro M. Optimistic replication[J]. ACM Computing Surveys (CSUR), 2005, 37(1): 42-81.
• 【6】Lamport L. Time, clocks, and the ordering of events in a distributed system[J]. Communications of the ACM, 1978, 21(7): 558-565.
• 【7】Bailis P, Ghodsi A, Hellerstein J M, et al. Bolt-on causal consistency[C]//Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data. ACM, 2013: 761-772.
• 【8】Terry D B, Demers A J, Petersen K, et al. Session guarantees for weakly consistent replicated data[C]//Parallel and Distributed Information Systems, 1994., Proceedings of the Third International Conference on. IEEE, 1994: 140-149.

传统一致性与分布式系统一致性的关系见http://blog.csdn.net/qiaojialin/article/details/72331161

分布式存储系统的一致性是一个很大的研究领域，其中关于一致性的定义也很丰富，看了一些一致性标准，现在将这些一致性标准分分类，让知识图谱更清楚一点。

1、分类原则

分布式系统一致性可以从两个角度进行观察：

1. 客户的角度（client-centric：客户中心）：主要从用户的角度看系统一致性。

2. 系统的角度（data-centric：数据中心）：主要从系统如何对操作进行调度的角度看。

   • 背景知识：系统中的数据分两个层次，上层是 逻辑数据项，底层是 物理的副本。

   逻辑数据项是可以直接被用户操作的，读写接口也都是用户针对逻辑数据进行的操作。如读取A的值，将B的值写为2等。

   副本则是系统为了性能和可用性使用的技术，对用户不可见，系统接收到用户对逻辑项的操作后，将转化为对底层副本的操作，这个转化规则就是副本控制策略。

那么如何分类呢：

• 客户中心一致性：定义了系统为用户对逻辑项的操作提供的保证。包括系统对一个客户端会话操作的保证和系统对多个客户端操作的保证。

• 数据中心一致性：定义了系统将对逻辑项的操作转化为对副本的操作时要满足的条件，即副本调度策略。不同的一致性对应不同的副本调度策略约束。

2、Client-centric（客户中心）一致性

2.1、单客户端

单客户端也称为单会话，以下四种一致性保证也叫做会话保证（session guarantee）【8】

1. 读你所写一致性：

   • 定义1：一个客户端A，更新了一个数据后，自己总能读到这个更新的值。（This is an important model where process A, after having updated a data item, always accesses the updated value and never sees an older value. This is a special case of the causal consistency model.【4】）

   • 定义2：读操作反应之前的写操作。（read operations reflect previous writes【8】）

     这个可以从因果一致性来理解，相当于自己更新了一个值，然后告诉了自己，所以自己后面都能读到这个值，或者更新的值。

2. 单调读一致性：

   • 定义1：一个客户端如果看到了一个对象的一个特定的值，那么其后续的读不会读到更旧的值了。（If a process has seen a particular value for the object, any subsequent accesses will never return any previous values.【4】）

   • 定义2：成功的读操作反应一个非减的写操作集合（successive reads reflect a non- decreasing set of writes.【8】）

   这个也可以从因果一致性来理解，相当于自己读到了一个值，然后告诉了自己，所以自己后面都能读到这个值，或者更新的值。

3. 单调写一致性：

   • 定义1：系统保证同一个客户端的多个写操作被串行化。（The system guarantees to serialize the writes by the same process. Systems that do not guarantee this level of consistency are notoriously difficult to program.【4】）

   • 定义2：写操作传播到之前写操作之后。（writes are propagated after writes that logically precede them.【8】）

   举例：客户端按顺序提交写请求（写a=1，写a=2），系统保证对这两个操作按顺序应用到逻辑项a上。即a的值先变为1，再变为2。而中间有没有其他值不保证。

4. 读后写一致性：

   • 定义1：会话对读到的数据项的写操作会改变此数据项的值。【本文定义】

   • 定义2：在读到了依赖的数据后，才在这些数据上进行写操作。（writes are propagated after reads on which they depend.【8】）

   例：一个会话执行了一些读操作，读到了a=1，然后这个会话再发送了一个写请求a=2，则数据项a的值应该迟早从1变到2。中间可以插入其他并发写操作。

   这个客户端一致性比较诡异，因为对用户看起来像是句废话。原始的定义为（writes are propagated after reads on which they depend）。尽管这里说的传播指传播到节点上，但是这样就有点副本的概念了，而用户应该感受不到副本的存在和多个节点。而其他人对单客户端的一致性只介绍了前三种，不包括读后写，所以在这里对其原始定义进行修改，强行解释一波。。。

2.2、多客户端

1. 强一致性：写成功后，后续所有读操作都能读到新值。（After the update completes, any subsequent access will return the updated value.【4】）

   举一个底层副本不一致但是能保证强一致的例子，Cassandra中 W + R > N 时，副本不一定一致，但是能保证写操作成功后后续读操作能返回最新的值。可以看到，客户端的一致性与底层数据的一致性并没有强关联。

2. 弱一致性：写操作完成后，系统不保证后续操作能读到新值，如果要读到新值，需要满足一定的条件。（The system does not guarantee that subsequent ac- cesses will return the updated value. A number of conditions need to be met before the value will be returned.【4】）

   这里的弱一致性是从客户端角度来说的，所以客户确实不知道什么时候能读到新值，可能有时候新有时候旧，这也是在弱一致系统上进行应用开发时面临的困难，如果想给用户提供一致的感觉，需要应用程序进行更多的逻辑处理和缓存，从而将底层存储系统的不一致解决在应用层。

3. 最终一致性：最终一致性的一种特例，如果一个对象没有新的写操作了，最终所有对这个对象的读操作会返回最后更新的值。（This is a specific form of weak consistency; the storage system guarantees that if no new updates are made to the object, eventually all accesses will return the last updated value【4】）

   从这里可以看出最终一致性是对系统中每个对象的性质。即使其他对象还有新的写操作，也不影响这个对象的收敛。

4. 因果一致性

   因果关系【6】（happen before relation）：-> 1.如果a和b实在一个进程中的操作，并且a在b前面，则a->b2.如果a是一个进程发送的消息，b是另一个进程的接收操作，接收到同样消息，则a->b3.如果a->b并且b->c，则a->c

   定义1：如果客户端A告诉客户端B更新了一个值，那么B的所有后续访问都会读到这个新值，并且同一个进程后面的写操作会取代前面的写操作。对于其他客户则没有这个保证。(If process A has communicated to process B that it has updated a data item, a subsequent access by process B will return the updated value, and a write is guaranteed to supersede the earlier write. Access by process C that has no causal relationship to process A is subject to the normal eventual consistency rules.【4】)

   这些都是客户端的因果关系，（A告诉B更新了一个值 -> B能读到新值），（同一个进程中两个写操作w1->w2，w2会在w1后执行）。

   定义2：因果一致性保证读操作会遵守写操作之间的因果关系，如果一个事件A影响了后续的操作B，客户端如果要看到B，必须也能看到A。（Causal consistency guarantees that reads will obey causality relationships between writes: if one event “influences” a subsequent operation, a client cannot observe the second without the first【7】 ）

   因果关系在客户端主要是从读操作中体现的，因为客户只能通过读操作观察系统行为。而系统中用户能看到的数据都是通过写操作产生的，所以因果一致性主要保证读操作能读到写操作间的因果关系。（读操作的功能也包括为写操作之间建立因果关系，比如进程A读到了进程B的写操作w1，并且A又发了一个写操作w2，那么系统只要保证w1->w2就可以了。）

2.3、客户中心一致性总结

客户端一致性是从应用的层面说的，一般用来系统开发人员向用户介绍系统，而用户主要是应用开发者，主要关心系统的读写特性，即客户端角度的一致性，一般不关心系统是如何实现的。

3、Data-centric一致性：相互一致性

3.1、 相互一致

定义：如果系统中每个数据项的所有副本的值都相同。那么系统处于相互一致的状态。（A replicated database is said to be in a mutually consistent state if all the replicas of each of its data items have identical values.【3】）

相互一致是一个形容词，在这里没有程度的区别，只有满足或不满足。

3.2、相互一致性

1. 相互一致性说的是所有副本收敛到同一个状态，并且当更新活动结束时副本值都一样（By mutual consistency we mean that all copies converge to the same state and would be identical should update activity cease）【1】

   相互一致性是一个性质，这个性质有不同的标准，更新活动停止不是写操作提交，写操作提交后继续传播写操作也可以称为更新活动。

2. 系统是一致的，如果所有副本都相同，并且所有操作满足一种特定一致性模型的顺序要求（A system is in a consistent state, if all replicas are identical and the ordering guarantees of the specific consistency model are not violated.【2】）

   这个定义从相互一致的概念出发，即系统最终是相互一致的。并强调不同的一致性标准的操作调度策略不同。

3. 数据库达到相互一致的状态指多个副本的值一样，区别不同相互一致性标准的是副本同步的紧密程度（A replicated database is said to be in a mutually consistent state if all the replicas of each of its data items have identical values. What differentiates different mutual consistency criteria is how tightly synchronized replicas have to be.）【3】

   前半部分在定义相互一致，而不同的相互一致性的区别在于副本同步的严格程度，这个同步的严格程度包括顺序要求和时间要求，强一致要求写操作提交时就要相互一致，这是时间要求。而因果一致则是顺序要求。

4. 定义总结：不同的相互一致性标准对应不同的副本控制策略，副本控制策略负责将客户对数据项的读写操作转化为多个副本上的读写操作序列。根据更新事务完成时副本是否一致区分一致性的强弱，其中弱一致性也称为最终一致性。

   相互一致性对副本的同步方式做了要求，这个同步方式指副本上操作的完成时间与逻辑操作的完成时间之间关系。也包括副本变化的顺序要求。不同的副本控制机制满足不同的相互一致性要求，系统开发人员可以参考相互一致性来进行系统实现。一般认为，一个节点本地执行的写操作都能被本地读操作读到。假设每个节点都保存了所有数据副本。

3.3、相互一致性种类：

1. 强相互一致性：当更新事务提交时，所有副本处于相互一致的状态。（Strong mutual consistency criteria require that all copies of a data item have the same value at the end of the execution of an update transaction.【3】）

   这里的强一致对副本进行操作的时间做了约束，对逻辑数据项的操作完成前要在所有副本上执行写操作。

2. 弱相互一致性：弱相互一致性不要求更新事务结束时副本都一样，但要求更新活动停止了一段时间，多个副本的值最终要一样。（Weak mutual consistency criteria do not require the values of replicas of a data item to be identical when an update transaction terminates. What is required is that, if the update activity ceases for some time, the values eventually become identical. This is commonly referred to as eventual consistency【3】）

   验证了一致性标准中除了强一致都是弱一致。而各种一致性标准都经历了数据从不一致到一致的过程。如果最终数据都不一致，那就不具有任何相互一致性了。

3. 最终一致性：

   • 定义1

     最终一致性表示如果用户停止提交新的操作，每个副本最终到达相同的最终值（eventual consistency means that replicas eventually reach the same final value, if users stop submitting new operations.【3】【5】）。

   • 定义2【5】

     调度队列等价：如果从同样的初始状态，能产生相同的结束状态，则两个调度队列是等价的。

     为了解决冲突，允许操作 α 在调度队列中，但是不执行，用 非α 表示。

     一个多副本对象是最终一致的，当满足以下几个条件时（假设所有初始状态相同）1.任意时刻，对每个副本，都有一个调度队列前缀（称为 提交前缀 ）与其他每个副本的调度队列前缀等价。2.每个副本的提交前缀是单调增长的。3.提交前缀中所有非空操作满足其先决条件。4.客户的每个请求操作 α ，α 或者 非α 最终会被添加到提交前缀中。

     【3】中提到，这种定义过于严格，尤其是“任意时刻调度前缀相同”和“调度前缀单调增长”，很多宣称提供最终一致性的系统都不满足这些要求。

   • 本文定义：最终一致性就是最终副本都要变成最后更新的值。

     数据的变化顺序不要求，只要求最终的值相同，对应很多实现方式。其实与弱一致性的定义没有本质区别。

4. 因果一致性：因果一致性并没有副本层面的定义，但是可以对应到副本操作层面，即满足因果一致性的副本控制策略。当系统检测到两个写操作w1，w2有因果关系w1->w2，那么在任意一个节点如果要执行w2，必须先执行w1。

   系统对外界展示的数据都是写操作的结果，读操作只用来建立写操作之间的因果关系，所以系统中只要保证写操作之间的因果关系就可以了。假如两个写操作有因果关系w1->w2，任意节点对w1和w2的执行顺序只有三种情况，{w1，w2}，{w1}，{}。

3.4、相互一致性总结

相互一致性对应着副本控制策略，即客户端发起的对逻辑数据项的读写请求如何在多个副本上进行调度，系统开发人员主要关注这方面的一致性来进行系统开发。