CAP与最终一致性（转载）

http://blog.csdn.net/starxu85/article/details/5399183

CAP原理(CAP Theorem)

在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP原理中，有三个要素：

一致性(C onsistency)
可用性(A vailability)
分区容忍性(P artition tolerance)

CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求 ，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性 即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。

最终一致性(eventually consistent)

对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性 。如果能容忍后续的部分或者全部访问不到，则是弱一致性 。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为：

因果一致性 。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。

“读己之所写（read-your-writes）”一致性 。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。

会话（Session）一致性 。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。

单调（Monotonic）读一致性 。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。

单调写一致性 。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

上述最终一致性的不同方式可以进行组合，例如单调读一致性和读己之所写一致性就可以组合实现。并且从实践的角度来看，这两者的组合，读取自己更新的数据，和一旦读取到最新的版本不会再读取旧版本，对于此架构上的程序开发来说，会少很多额外的烦恼。

从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统：

N — 数据复制的份数
W — 更新数据是需要保证写完成的节点数
R — 读取数据的时候需要读取的节点数

如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。

如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。

对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。
如果N=R,W=1，只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据，因此是弱一致性。这种情况下，如果W<(N+1)/2，并且写入的节点不重叠的话，则会存在写冲突

CAP与最终一致性（转载）相关推荐

CAP, BASE, 最终一致性和五分钟原则
CAP,BASE和最终一致性是NoSQL数据库存在的三大基石.而五分钟法则是内存数据存储的理论依据.这个是一切的源头. CAP C: Consistency 一致性 A: Availability ...
CAP BASE 最终一致性
女主宣言 1998年,加州大学的计算机科学家 Eric Brewer 提出分布式系统有三个指标,即CAP,而这三个指标不能同时做到.今天小编就为大家分享分布式相关理论,希望能对大家有所帮助. PS:丰 ...
CAP原理和最终一致性(Eventually Consistency)
2019独角兽企业重金招聘Python工程师标准>>> 在足球比赛里,一个球员在一场比赛中进三个球,称之为帽子戏法(Hat-trick).在分布式数据系统中,也有一个帽子原理(CAP ...
「数据库系列四」分布式数据库CAP理论与最终一致性
传统关系型数据库中事务有四个重要的特性,简称ACID,即原子性 : 事务是一个不可分割的工作单位,事务中的操作要么都成功,如果有一个执行失败,所有的SQL将都被撤销,恢复到事务开始的状态一致性 : ...
分布式事务最终一致性-CAP框架轻松搞定
前言对于分布式事务,常用的解决方案根据一致性的程度可以进行如下划分: 强一致性(2PC.3PC):数据库层面的实现,通过锁定资源,牺牲可用性,保证数据的强一致性,效率相对比较低. 弱一致性(TCC) ...
nosql简答什么是最终一致性_NoSql的三大基石：CAP理论BASE最终一致性
关系型数据库的局限 NoSql出现在关系型数据库之后,主要是为了解决关系型数据库的短板,我们先来看看随着软件行业的发展,关系型数据库面临了哪些挑战: 1.高并发一个最典型的就是电商网站,例如双11, ...
cap与一致性（强一致性、弱一致性、最终一致性）
在足球比赛里,一个球员在一场比赛中进三个球,称之为帽子戏法(Hat-trick).在分布式数据系统中,也有一个帽子原理(CAP Theorem),不过此帽子非彼帽子.CAP原理中,有三个要素: 一致性 ...
base cap 分布式_分布式基础（1）:CAP原理、BASE思想和最终一致性
CAP,BASE和最终一致性是NoSQL数据库存在的三大基石. CAP C: Consistency 一致性 A: Availability 可用性(指的是快速获取数据) P: Tolerance o ...
DotNetCore.Cap分布式事务实现最终一致性
项目演化过程中,微服务已经遍地开花.一个大项目下几十上百个微服务已经是常态.但衍生出另外一个问题就是跨微服务事务,跨库事务的分布式事务.市面了解过的有2CP.3CP.TCC等等分布式事务解决方案,各有 ...

CAP与最终一致性（转载）

CAP与最终一致性（转载）相关推荐

最新文章

热门文章