文档章节

CAP原理和最终一致性(Eventually Consistency)

liangtee
 liangtee
发布于 2014/07/30 14:45
字数 1629
阅读 607
收藏 10

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

  • 一致性(Consistency)
  • 可用性(Availability)
  • 分区容忍性(Partition 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,并且写入的节点不重叠的话,则会存在写冲突  

© 著作权归作者所有

共有 人打赏支持
liangtee
粉丝 106
博文 94
码字总数 38111
作品 0
朝阳
程序员
私信 提问
分布式领域BASE理论-学习整理

BASE理论 : BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(Strong Consistency,CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency...

落叶刀
2016/01/20
119
0
科普一下,什么是分布式架构设计中的CAP原理?

大家在看书或者参加会议的时候,对于数据架构设计的时候,一定经常听到CAP原理,比如根据CAP原理,对于分布式设计系统,只能做到数据的最终一致性而不是实时事务的一致性;那么,这些行家或者...

chancein007
2016/12/18
0
0
《分布式服务架构:原理、设计与实战》第二章彻底解决分布式系统一致性的问题

1、什么是一致性 一致性指分布式服务化系统之间的弱一致性,包括应用系统的一致性和数据的一致性。无论是水平拆分还是垂直拆分,都解决了特定场景下的特定问题,但拆分后的系统或者服务化的系...

Lienson
昨天
0
0
漫谈事务与分布式事务(4)- 最终一致性

在上一篇文章里忽略了一点。 CAP 定理有一个缺陷,这个缺陷可以帮助我们“部分”摆脱 分布式困境。 总的来说,CAP 定理本身是完备的,但它并没有描述一个分布式系统何时产生分区,以及分区会...

长源
2014/04/08
0
0
分布式存储系统设计的若干原则

1、CAP理论 2000年Eric Brewer教授提出了著名的CAP理论,即:一个分布式系统不可能满足一致性,可用性和分区容错性这三个需求,最多只能同时满足两个。2002年MIT的Seth Gilbert 和 Nancy ly...

红薯
2011/08/10
405
1

没有更多内容

加载失败,请刷新页面

加载更多

开始看《ES6标准入门》

写得非常好,全是干货。还以为是很容易上手的,结果一看还是要有一些JS基础才行的 1.ES6简介。可以了解一下,特别是ES6和ES2015的关系 2.Let和Const命令。这个感觉是帮JS打补丁了。之前的Var...

max佩恩
39分钟前
1
0
SpringBoot入门系列HelloWorld

根据咱们程序员学习的惯例,学习一门新技术都是从HelloWorld开始的。 感觉编程是一件非常富有意义的事情,程序员也是一群可爱的人,渴望被关怀和关注,因为我们总在和世界say Hi. 好了进入正...

凌宇之蓝
今天
4
0
Linux之《荒岛余生》(二)CPU篇

温馨提示,动图已压缩,流量党放心查看。CPU方面内容不多,我们顺便学点命令。本篇是《荒岛余生》系列第二篇,垂直观测CPU。其余参见: Linux之《荒岛余生》(一)准备篇 如何做一个CPU cpu...

mskk
今天
1
0
Java基础教程,第十讲,继承

前面我们学习了类和对象的概念,学习了方法的重载,今天我们将学习面向对象另一个重要特性,继承(inheritance)。利用继承,我们可以基于一个已经存在的类狗仔一个新的类,继承已经存在的类...

程序员补给栈
今天
2
0
nginx的日志

nginx的日志包括错误日志和访问日志,分别使用不同的指令来定义其输出位置和相应的级别。 下面介绍其各自的用途。 错误日志 nginx提供了error_log指令来指定错误日志的输出文件和级别。 指令...

xtof
今天
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部