正确理解CAP定理
前言
CAP的理解我也看了很多书籍,也看了不少同行的博文,基本每个人的理解都不一样,而布鲁尔教授得定义又太过的简单,没有具体描述和场景案例分析。因此自己参考部分资料梳理了一篇与大家互相分享一下。
标题写了正确理解,或许某些点不是百分百正确或者有歧义,但是希望与各位分享讨论后达到最终正确,
简介
CAP定理,又被称作布鲁尔定理(Brewer's theorem),是埃里克·布鲁尔教授在2000 年提出的一个猜想,它指出对于一个分布式系统来说,不可能同时满足以下三点:
- Consistency(一致性): where all nodes see the same data at the same time.(所有节点在同一时间具有相同的数据)
- Availability(可用性): which guarantees that every request receives a response about whether it succeeded or failed.(保证每个请求不管成功或者失败都有响应)
- Partition tolerance(分隔容忍): where the system continues to operate even if any one part of the system is lost or fails.(系统中任意信息的丢失或失败不会影响系统的继续运作)
很多书籍与文章引用Robert Greiner在2014年8月写的一篇博文 http://robertgreiner.com/2014/08/cap-theorem-revisited/。相比与看着布鲁尔教授一脸懵逼的定义,Robert Greiner的更加容易理解。
定义
原文:In a distributed system (a collection of interconnected nodes that share data.), you can only have two out of the following three guarantees across a write/read pair: Consistency, Availability, and Partition Tolerance - one of them must be sacrificed.
翻译:在一个分布式系统(指互相连接并共享数据的节点的集合)中,当涉及读写操作时,只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个,另外一个必须被牺牲。
关键字:interconnected nodes(互连节点)、share data(共享数据)、a write/read pair(读/写)
从上面一段话,有几个,也就是说我们聊CAP定理的时候,是在具有数据读写、数据共享和节点互连的前提下,对上面三者选其二,也是建议我们不要花费时间与精力同时满足三者。
举例说明,web集群、memcached集群不属于讨论对象
- web集群只是资源复制分配在不同的节点上,然而节点间没有互连、也没有数据共享(sessionid、memory cache)。
- memcached集群数据存储是通过客户端实现哈希一致性,但是集群节点间不互连的,也没有数据共享。
总得来说,CAP定理讨论的并不是分布式系统所有的功能。
一致性(Consistency)
原文:A read is guaranteed to return the most recent write for a given client.
翻译:对某个指定的客户端来说,读操作保证能够返回最新的写操作结果
关键字:a given client(指定的客户端)。
这里的一致性与我们平常了解ACID的一致性有点偏差,ACID的一致性关注的是数据库的数据完整性。
上面定义没说明是所有节点必须在同一时间数据一致,而关注点在客户端,假如有个场景,您在ATM(客户端)往某张银行卡存500元后,立刻在ATM发起查询余额的时候会显示加了500元后的余额,随后我们也能把这500元取出来。查询余额读操作可以是写后立刻读的主库,也或者写后某个时间段过后(中途无写)读从库。
可用性(Availability)
原文:A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).
翻译:非故障节点将在合理的时间内返回合理的响应(不是错误或超时)。
关键字:non-failing node(非故障节点)、reasonable response(合理的响应)
这里的可用性和我们平常所理解的高可用性有点偏差,高可用性指系统无中断的执行其功能的能力。
已故障的节点就不具有可用性了,因为请求结果要么error要么 timeout。合理的响应没有说明是成功还是失败,但是响应应该具有是否成功的精确描述。例如我们读取sql server集群的某从库,同步需要时间,读取出来可能不是最新的数据,但却是合理的响应。
分区容错性(Partition tolerance)
原文:The system will continue to function when network partitions occur.
翻译:当网络分区发生时,系统将继续正常运作
关键字:continue to function(继续正常运作)
假如做了一个redis的一主两从的集群,某天某个从节点因为网络故障变成不可用,但是另外的一主一从仍然能正常运作,那么我们认为它具有分区容错性。
CA-牺牲分区容错性
作为分布式系统,分区必然总会发生(2年1次50分钟还是1年3次共10分钟?),因此认为CAP的讨论是大部分建立在P确立前提下。假设我们牺牲了P这个时候因为网络故障发生了分区导致节点不可用,这个时候请求响应了error、timeout,与可用性的定义相冲突了。
但是,我们又假如分区大部分时间是不存在的,这时对单节点的读\写,那么就无需作出C、A的取舍。但是上面说分区总会发生这不互相矛盾么,还是取舍。假如1年时间内99.99%时间是正常的,不可用时间为0.01%(52.56分钟)不可用,若这个时间属于业务接受范围,或者只在某个地区(华南、华北、华中?)有影响,那么CA也是可以选择的。
PC-牺牲可用性
最典型的案例是RDBMS集群与Redis集群,这两种都是利用主从复制实现读写分离的方案。假如两者都是建立一主多从的集群,在主节点写入数据,为了保证随后的读操作获取最新数据(一致性),这个读操作仍会请求主节点(读写分离的复杂点在从库同步不及时导致业务的异常,为了保证业务的正常性写后的读会请求主库),某个从节点挂了但是只要主节点和其他从节点仍然正常运作,就满足分区容错性。但是哪天主节点因为网络故障导致写操作的error或者timeout,那么这个系统就不可用了(牺牲可用性)。
这个时候可以引入其他功能和机制完成,例如Redis哨兵模式、故障转移功能。
PA-牺牲一致性
最典型的案例是Cassanda集群和Riak集群,这种类型的分布式数据库,可以任意节点写入,任意节点读取,当作为集群出现,无论写入哪个节点,都将会把该节点的数据同步到其他节点上,因为这种同步方式,读取数据时只要访问一个节点就足够了(喜欢任意访问也不拦着你),但是因为其他节点数据同步原因,数据可能并不是最新的(牺牲一致性)。如果当前节点因为网络异常导致分区变得不可用(无论读\写),可以转移访问节点(可用性)。
另外这里说的牺牲一致性,并不代表放弃一致性,而PA选择的是最终一致性(系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态)
总结
上面涉及“牺牲”字眼,并不代表非此即彼的选择,可以根据子系统、模块之间的设计上进行混搭使用(例如PA和PC、CA和PC)。
本文对CAP定理做了一个简单的梳理描述,参考了部分书籍和文章加上自己的理解希望可以跟大家做个分享,如果有不同建议和看法包括文章内描述错误,请在下方评论指出,我将及时作出修改。
正确理解CAP定理的更多相关文章
- 【转】.NET(C#):浅谈程序集清单资源和RESX资源 关于单元测试的思考--Asp.Net Core单元测试最佳实践 封装自己的dapper lambda扩展-设计篇 编写自己的dapper lambda扩展-使用篇 正确理解CAP定理 Quartz.NET的使用(附源码) 整理自己的.net工具库 GC的前世与今生 Visual Studio Package 插件开发之自动生
[转].NET(C#):浅谈程序集清单资源和RESX资源 目录 程序集清单资源 RESX资源文件 使用ResourceReader和ResourceSet解析二进制资源文件 使用ResourceM ...
- 关于CAP定理的个人理解
CAP定理简介 在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点: 一致性(C ...
- 对CAP定理的理解
CAP定理的常规解释是任何分布式系统只能在一致性(Consitency),可用性(Availability)和分区容忍性(Partition Tolerance)中三选二.这个解释很让人费解,笔者在看 ...
- 佳文分享:CAP定理
1976年6月4号,周5,在远离音乐会大厅的一个楼上的房间内,在位于Manchester的Lesser Free Trade Hall ,Sex Pistols 乐队(注:Sex Pistols的经理 ...
- 架构设计之「 CAP 定理 」
在计算机领域,如果是初入行就算了,如果是多年的老码农还不懂 CAP 定理,那就真的说不过去了.CAP可是每一名技术架构师都必须掌握的基础原则啊. 现在只要是稍微大一点的互联网项目都是采用 分布式 结构 ...
- 【翻译】Brewer's CAP Theorem CAP定理
Brewer's CAP Theorem 原文地址:http://www.julianbrowne.com/article/brewers-cap-theorem Brewer’s (CAP) The ...
- CAP定理在分布式系统设计中的最新应用
本文翻译自国外InfoQ和计算机杂志上一篇2012年旧文,本文就有关数据同步进行了讨论,特别关注业务事务的不变性与一致性如何在分布式系统中巧妙保证,探讨了长时间运行的事务的补偿机制.这些对分布式系统设 ...
- 架构师都该懂的 CAP 定理
面对可能出现的网络延迟,不可预估的请求流量等情况,设计一个分布式系统,我们通常围绕系统高可用,数据一致性的目标去规划和实现,想要完全实现这个目标,却并非易事.由此,分布式系统领域诞生了一个基本定理,即 ...
- 关于ACID,BASE和CAP定理的探究
前言 当我看到"根据CAP理论,由于分布式系统必须保证分区容错性,所以只能选择AP原则或者CP原则"这种结论时,我感到很疑惑: 什么是分区容错性? 为什么分布式系统必须保证分区容错 ...
随机推荐
- Hive内部表与外部表的区别
1.未被external修饰的是内部表[managed table],被external修饰的为外部表[external table]. 2.内部表数据由Hive自身管理,外部表数据由HDFS管理. ...
- Keras实现VGG16
一.代码实现 # -*- coding: utf-8 -*- """ Created on Sat Feb 9 15:33:39 2019 @author: zhen & ...
- Weblogic java生成wlfullclient.jar
进入weblogic的server\lib目录 cd G:\Oracle\Middleware\wlserver_10.3\server\lib 运行 java -jar G:\Oracle\Midd ...
- vs添加到附加进程调试(IIS页面调试)
有时候单元测试不是很方便,通过页面调试接口会更直观,也跟容易发现问题(尤其是在页面传参的时候),这时vs添加到附加进程的调试方式就显得尤为重要了! 步骤如下: 1.首先是通过IIS建立网站,(前提是要 ...
- 解决tomcat中文传输乱码问题
<Connector URIEncoding="utf-8" connectionTimeout="20000" encoding="utf-8 ...
- C#判断文件编码——常用字法
使用中文写文章,当篇幅超过一定程度,必然会使用到诸如:“的”.“你”.“我”这样的常用字.本类思想便是提取中文最常用的一百个字,使用中文世界常用编码(主要有GBK.GB2312.GB18030.UTF ...
- jvm程序执行慢诊断手册
生产环境最多的几种事故之一就是程序执行慢,如果是web服务的话,表现就是响应时间长.本文分享,从业多年形成的排查守则. 诊断步骤 系统资源查看 首先是系统资源查看,而且必须是在第一步.因为很多事故都是 ...
- django静态模版使用
第一步:在app目录下建立static文件夹,将CSS文件.js文件放到static文件夹下 第二步:TEMPLATES = [ { 'BACKEND': 'django.template.backe ...
- 【2018.08.13 C与C++基础】C++语言的设计与演化读书笔记
先占坑 老实说看这本书的时候,有很多地方都很迷糊,但却说不清楚问题到底在哪里,只能和Effective C++联系起来,更深层次的东西就想不到了. 链接: https://blog.csdn.net/ ...
- JavaScript函数式编程
一段糟糕透顶的海鸥seagulls程序 鸟群合并conjoin则变成了一个更大的鸟群,繁殖breed则增加了鸟群的数量,增加的数量就是它们繁殖出来的海鸥的数量 //Flock 群 var ...