大规模数据处理实战
蔡元楠
Google Brain资深工程师
立即订阅
8405 人已学习
课程目录
已完结 46 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从这里开始,带你走上硅谷一线系统架构师之路
免费
模块一 | 直通硅谷大规模数据处理技术 (3讲)
01 | 为什么MapReduce会被硅谷一线公司淘汰?
02 | MapReduce后谁主沉浮:怎样设计下一代数据处理技术?
03 | 大规模数据处理初体验:怎样实现大型电商热销榜?
模块二 | 实战学习大规模数据处理基本功 (8讲)
04 | 分布式系统(上):学会用服务等级协议SLA来评估你的系统
05 | 分布式系统(下):架构师不得不知的三大指标
06 | 如何区分批处理还是流处理?
07 | Workflow设计模式:让你在大规模数据世界中君临天下
08 | 发布/订阅模式:流处理架构中的瑞士军刀
09 | CAP定理:三选二,架构师必须学会的取舍
10 | Lambda架构:Twitter亿级实时数据分析架构背后的倚天剑
11 | Kappa架构:利用Kafka锻造的屠龙刀
模块三 | 抽丝剥茧剖析Apache Spark设计精髓 (10讲)
12 | 我们为什么需要Spark?
13 | 弹性分布式数据集:Spark大厦的地基(上)
14 | 弹性分布式数据集:Spark大厦的地基(下)
15 | Spark SQL:Spark数据查询的利器
16 | Spark Streaming:Spark的实时流计算API
17 | Structured Streaming:如何用DataFrame API进行实时数据分析?
18 | Word Count:从零开始运行你的第一个Spark应用
19 | 综合案例实战:处理加州房屋信息,构建线性回归模型
20 | 流处理案例实战:分析纽约市出租车载客信息
21 | 深入对比Spark与Flink:帮你系统设计两开花
模块四 | Apache Beam为何能一统江湖 (8讲)
22 | Apache Beam的前世今生
23 | 站在Google的肩膀上学习Beam编程模型
24 | PCollection:为什么Beam要如此抽象封装数据?
25 | Transform:Beam数据转换操作的抽象方法
26 | Pipeline:Beam如何抽象多步骤的数据流水线?
27 | Pipeline I/O: Beam数据中转的设计模式
28 | 如何设计创建好一个Beam Pipeline?
29 | 如何测试Beam Pipeline?
模块五 | 决战 Apache Beam 真实硅谷案例 (7讲)
30 | Apache Beam实战冲刺:Beam如何run everywhere?
31 | WordCount Beam Pipeline实战
32 | Beam Window:打通流处理的任督二脉
33 | 横看成岭侧成峰:再战Streaming WordCount
34 | Amazon热销榜Beam Pipeline实战
35 | Facebook游戏实时流处理Beam Pipeline实战(上)
36 | Facebook游戏实时流处理Beam Pipeline实战(下)
模块六 | 大规模数据处理的挑战与未来 (4讲)
37 | 5G时代,如何处理超大规模物联网数据
38 | 大规模数据处理在深度学习中如何应用?
39 | 从SQL到Streaming SQL:突破静态数据查询的次元
40 | 大规模数据处理未来之路
专栏加餐 | 特别福利 (4讲)
FAQ第一期 | 学习大规模数据处理需要什么基础?
加油站 | Practice makes perfect!
FAQ第二期 | Spark案例实战答疑
FAQ第三期 | Apache Beam基础答疑
结束语 (1讲)
结束语 | 世间所有的相遇,都是久别重逢
大规模数据处理实战
登录|注册

09 | CAP定理:三选二,架构师必须学会的取舍

蔡元楠 2019-05-06
你好,我是蔡元楠。
今天我要与你分享的主题是 CAP 定理。
在分布式系统的两讲中,我们一起学习到了两个重要的概念:可用性和一致性。
而今天,我想和你讲解一个与这两个概念相关,并且在设计分布式系统架构时都会讨论到的一个定理——CAP 定理(CAP Theorem)。

CAP 定理

CAP 这个概念最初是由埃里克·布鲁尔博士(Dr. Eric Brewer)在 2000 年的 ACM 年度学术研讨会上提出的。
如果你对这次演讲感兴趣的话,可以翻阅他那次名为“Towards Robust Distributed Systems”的演讲 deck。
在两年之后,塞思·吉尔伯特(Seth Gilbert)和麻省理工学院的南希·林奇教授(Nancy Ann Lynch)在他们的论文“Brewer’s conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services”中证明了这一概念。
他们在这篇论文中证明了:在任意的分布式系统中,一致性(Consistency),可用性(Availability)和分区容错性(Partition-tolerance)这三种属性最多只能同时存在两个属性。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《大规模数据处理实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(65)

  • 常超 置顶
    关于大家出现很多疑问的Kafka是否有P属性的问题,上网搜了一下,找到一个可以说明Kafka不具备P属性的例子,不知道理解对不对,请老师和大家批评指正。

    比如:在以下的场景序列下,会出现数据写入丢失的情况,所以不能说kafka是有P属性

    前提:leader和两个slave 1、2
    序列:
    1.机器leader跟两个slave之间发生partion
    这是leader成为唯一服务节点,继续接受写入请求w1,但是w1只保存在了leader机器上,无法复制到slave1和2
    2.leader和zookeeper之间发生partition,导致kafka选取slave 1为新leader,新leader接受新写入w1
    这时候,上面1的w1写入丢失了。即使之后旧leader复活,w1的写入数据也不会被恢复出来。
    参考:https://bit.ly/2VGKtu1

    作者回复: 常超您好,又看到了您的留言!其实归根结底P属性还是说当Network Partition发生后,无论后面网络分区是否会恢复,分离出来的子系统都可以正常运行。您所说这几个例子确实是讲到了在Kafka Replication中,有的节点在分区后就无法再使用了,所以设计的时候并没有考虑P属性。另外还多加一句,并不是Kafka没有P属性,而是Intra-cluster Kafka Replication没有P属性。

    谢谢你的参考资料,这对我和其他读者们来说都非常有帮助!

    2019-05-06
    16
  • 常超 置顶
    老师您好,文中说kafka放弃了P属性。
    但是从后面的解释来看,即使出现分区(领导者节点和副本1无法通讯),整个系统也能正常工作,这种行为难道不是保持了P属性吗。您能否举一个P属性被放弃的例子?

    作者回复: 常超您好,感谢您的提问!

    关于这个问题我是这么看的。当我们在分布式环境中讨论CAP属性的时候,P属性可以说是当任意节点断开后,系统还是可以正常的运行。对于整个Kafka系统来说,P当然是必须要保留的。可当你只从Kafka Replication来看的时候,如果一个cluster里面领导者挂掉了,单单就这个cluster来说有再多的副本存在也是无法运行了,所以就Kafka Replication来说,它没有保留P属性。

    而在Kafka Replication的设计中为什么说P被放弃了呢,引用Kafka的作者之一Jun Rao在设计Kafka Replication的说法,是因为“All distributed systems must make trade-offs between guaranteeing consistency, availability, and partition tolerance. Our goal was to support replication in a Kafka cluster within a single datacenter, where network partitioning is rare, so our design focuses on maintaining highly available and strongly consistent replicas.”,这一点是在Linkedin的Engineering官方文档上publish的。而在2013年的Apachecon上,Kafka Replication的技术演讲上也明确说明了“Kafka Replication: Pick CA”。

    不知道我的解释能否让您更好地理解,也欢迎您继续留言提问,我们一起学习进步!

    2019-05-06
    1
    6
  • 王燊 شن ون 置顶
    我的理解:A是机器挂掉仍可用,P是网络挂掉仍可用。如果我的理解正确,那老师您说Kafka不支持P的解释,即当Kafka leader挂掉整个系统不可用,其实是不是表明Kafka是不支持A,而不是不支持P的?

    作者回复: 谢谢你的留言!你的理解非常正确,A就是指集群中即便挂掉几个机器但是集群对外还是正常运行的,P就是指即便机器间无法通讯了但是集群对外还是正常运行。

    我对于Kafka Replication pick CA这种设计的理解是,设计师只考虑了在Replication的集群里对CA的保证而放弃了对P的保证。所以当发生Network Partition的时候,系统有可能可以工作,有可能不能继续工作。例如说C的保证是因为Kafka Replication要求了领导者节点的数据一定要同步数据副本节点上,否则不会返回这个数据;A的保证是因为无论有多少数据副本节点挂了,只要领导者节点不挂,这个Replication集群都可以返回数据,但是当领导者挂了,这整个Replication集群就不能再用了,而没了这个集群也就没有CAP属性可言了。希望这能帮助你理解,如果有不明确的地方也欢迎你继续留言提问,一起学习进步。

    2019-05-10
    1
    5
  • 置顶
    AP,发微博保证最终一致性就可以。
    疑问一,mongodb采用CP,那么它在可用性方面有做什么事情吗?
    疑问二,kafka这种通过选举leader的方式不就是分区容错性吗?为什么说放弃了P呢?

    作者回复: 谢谢你的答案。

    关于疑问一:MongoDB的设计默认是希望读写有strong consistency的。当然MongoDB也有自身的Replica Set来保证可用性:https://docs.mongodb.com/manual/replication/#replication-in-mongodb
    关于疑问二:你说的没有错,作为多个data clusters来说,Kafka系统是不可能放弃P的,不然一旦leader挂掉系统就没有任何结果可以返回了。但是我在这一讲中所讲述的Intra-cluster Kafka Replication Design是对于一个cluster来说。就像我回答其他有同样疑问的读者一样,之所以我在文中说Kafka Replication选择了CA,是因为Kafka的作者之一Jun Rao在设计Kafka Replication的时候,明确说明了“All distributed systems must make trade-offs between guaranteeing consistency, availability, and partition tolerance. Our goal was to support replication in a Kafka cluster within a single datacenter, where network partitioning is rare, so our design focuses on maintaining highly available and strongly consistent replicas.”,这一点是在Linkedin的官方文档上publish的。而在2013年的Apachecon上,Kafka Replication的技术演讲上也明确说明了“Kafka Replication: Pick CA”。

    学习之后提出疑问是一个很好的习惯,也希望后面继续看到你的留言!

    2019-05-06
    1
    1
  • Codelife
    严格来说,CAP理论是针对分区副本来定义的,之所以说kafka放弃P,只支持CA,是因为,kafka原理中当出现单个broke宕机,将要出现分区的时候,直接将该broke从集群中剔除,确保整个集群不会出现P现象

    作者回复: 谢谢你的留言!你的理解非常正确,就是因为这样Kafka Replication的设计中不需要考虑到P的存在,让整个Replication Design成为CA系统。

    2019-05-06
    11
  • mccrms
    文中提到的CA示例其实是有很强的误导性的。

    首先我们要明确如下的事实:
    1)对于一个分布式系统而言,节点故障和网络故障属于常态
    2)如果出现网络故障,会造成节点分区
    3)分布式系统在存在节点分区的情况下,C和A是冲突的

    通过上面的事实我们可以推断出,如果想设计出一个CA系统,必须保证网络不出现分区才有可能,怎样保证网络不出现分区呢,一是单台机器,二是像例子中所述,将所有节点放在同个数据中心中可以假定网络出现分区的概率很低。这也是为什么例子中的情况可以假装称为CA。

    还有一些需要辅助理解CAP的知识如下:
    1)对于分布式系统而言,最简单可以分为两种,一是所有节点通过都可以通过某种策略对外提供服务,是对等的,二是所有节点通过一个master对外提供服务,甚至是一个单点的master
    2)探讨系统CAP的前提应该是系统在能提供服务的情况下的CAP,如果存在master单点,但是有很多从属worker的话,这时的可用性探讨需要划分为worker故障和master故障来看。对于文中的例子master如果挂掉系统不可用则表名A其实也是勉强的

    CAP Theorem is like the old joke about software projects: you can have it on TIME, in BUDGET, or CORRECT. Pick any two😀

    CAP三者互相制衡,应该是看侧重哪两个,而不是选了哪两个,不是两个100分剩下的一个0分,本质上都要兼顾的。
    2019-06-03
    1
    10
  • 桃园悠然在
    另外,增加一个评论:蔡老师的文章头图每张都跟内容强相关(不知是否自己P图或者照相的),而且右上角有文章序号很用心,点赞!

    作者回复: 谢谢你的支持,哈哈!

    2019-05-06
    3
  • 王聪 Claire
    kafka 的replication机制,即使出现分区这样的错误,系统也能够通过领导者节点返回消息。怎么算放弃了P呢?谢谢。

    作者回复: 谢谢你的提问!我的理解是如果仅仅就一个Kafka Replication cluster来说,如果领导者挂了我们就不会再从这个cluster拿到内容了,所以在Intra-cluster Replication这个设计点上,他们是不考虑P的。

    之所以我在文中说Kafka Replication选择了CA,是因为Kafka的作者之一Jun Rao在设计Kafka Replication的时候,明确说明了“All distributed systems must make trade-offs between guaranteeing consistency, availability, and partition tolerance. Our goal was to support replication in a Kafka cluster within a single datacenter, where network partitioning is rare, so our design focuses on maintaining highly available and strongly consistent replicas.”,这一点是在Linkedin的官方文档上publish的。而在2013年的Apachecon上,Kafka Replication的技术演讲上也明确说明了“Kafka Replication: Pick CA”。

    所以你会发现,他们的设计思路是仅仅就Intra-cluster的data replication出发的。当然,如果从整个Kafka系统来说,是不可能放弃P的。

    2019-05-06
    3
  • coldpark
    有一个形象的比喻不知道恰当不恰当,一个系统相当于一个团队,有C属性说明这个团队每次都能保质保量完成任务,A属性说明这个团队每次都能及时完成任务,P属性相当于这个团队内部偶尔会犯一些小错误。犯错是很常见的,所以一般都具有P属性。
    CP类型的团队对外的形象相当于:我的团队不是完美的,但我的产品绝对不会出问题,只要你给我足够的时间让我们把问题排查清楚。
    AP类型的团队给人的感觉就是:人非圣贤,孰能无过,我的队员会犯错,我的团队也有估计不足的时候,但是客户的需求我们总会最快响应。
    CA类型的团队有个强人领袖(leader节点):任何事务无论大小都过问一遍,一旦发现手下有人犯错,立马剔除出团队,如果自己犯错,让出领袖地位,整个团队一定要保证最快最好完成任务。

    作者回复: 是有一定道理

    2019-08-11
    2
  • Zoe
    查了查文档,对于Kafka没有考虑P因素,是因为相同的partition (leader和replications)都在同一个data center里,大概是说不需要去考虑P。

    但对于同时满足CA还请老师再解释一下。文档里说,可以config availability over durability,也可以反之。
    如果选择availability的话,设置acks=all,可以保证isr里登记在册的broker都接收到信息,但isr里也可能只有leader一个。所以当leader挂了之后到再选出新leader期间就有数据丢失的可能性。
    如果选择durability的话可以设置min_insync_replicas,但如果小于这个threshold的时候,不是得等着某个broker恢复,这样不就牺牲availabilty了吗?

    所以,到底C和A是如何都满足的?
    2019-05-28
    1
    2
  • 刘晓林
    老师,我好像懂了。kafka replication不保证p,指的是当网络出现分区后,和主有一台副本比如replicatin1和leader失联了,那replication1就会被踢出去,相当它于宕机了。在这里,分区导致replication1不可用了,所以说不保证p。
    是这样理解吗?

    作者回复: 谢谢你的再次留言!是的,理解正确!既然replication1对于集群来说现在以及以后都不可用了,也就相对于集群没有了这个replication1,那也就不存在说网络分区后replication1还是否在集群正常运行的问题了。

    2019-05-12
    2
  • 桃园悠然在
    我理解kafka作为一个消息系统平台,是不允许消息丢失的,所以通过replication机制冗余数据保证。但是P属性更像是一个缺点(容忍了消息丢失),它的好处该怎么理解呢?谢谢老师!

    作者回复: 谢谢你的留言!P属性的好处是在分布式环境下,无论网络发不发生分区,整个系统都可以照常运行。不管分区后用户读到的是stale data,还是up-to-date data。像常超同学的留言中举了几个例子,如果系统设计上没有了P属性,很多时候network partition发生了, 那剩下的一些节点可能就无法再用了,最坏的情况下可能整个系统都无法运行下去。

    2019-05-06
    2
  • LaimanYeung
    A:集群某个或某几节点挂掉时,客户端仍然可以访问服务端.
    C:客户访问集群中任一服务端,返回的状态都是一致的.
    P:集群内部机器通讯出现问题导致服务A的数据无法同步到其他节点时,客户端访问服务A,服务A扔能返回未同步到其他节点的数据.

    作者回复: 谢谢你的总结!非常棒!

    2019-05-12
    1
  • 刘晓林
    不太理解ca系统,允许有机子挂掉,却不允许网络分区。机子都挂掉了,到这台机子的网络可不就是连不通了吗? 允许机子化掉却不允许机子和集群失联,这是个悖论呀。怎么理解这个呢老师

    作者回复: 谢谢你的留言!其实选择CA的系统是少之又少,你的问题里面提到了一个关键点,当机子挂掉的时候或者当网络分区出现的时候,系统会直接将这个机子从集群中剔除掉了,也就是说无论以后这个机子处于什么状态都不会再出现在这个集群中,在集群中剩下的机子数据一直都是同步的,所以就有了有CA却不存在P的说法了。不知道这个解释你觉得怎么样,同时也欢迎你不理解的话继续提问。

    2019-05-11
    1
  • 刘万里
    老师,您有apache beam相关的书推荐吗?谢谢

    作者回复: 谢谢你的留言!现在来说还没有专门介绍Apache Beam的书籍,不过如果你想了解底层思想的还,可以看Tyler Akidau写的Streaming Systems。

    2019-05-07
    1
  • 利利
    1. kafka作为CA系统的理解:
          kafka的设计是只需要保证单个数据中心的broker之间能够数据复制就好,出现网络分区的情况比较少,因此他主攻高可用和强一致性
    2. 文中,老师提到kafka的Leader选举是由Zookeeper选举的,这儿有点不严谨
         原因:kafka会由Zookeeper选举一台broker作为controller,之后由controller来维护partition的leader、flower,而leader宕机之后进行新leader的选举也是由controller负责的
    3. 微博发微博的功能,满足AP就行,C的话只需要是最终一致性就好,就跟微信朋友圈一样

    作者回复: 谢谢你的留言!
    1. 是的呢,Kafka Replication的设计思想就是因为一个数据中心中很少会出现Network Partition所以主攻高可用和强一致性。你的理解是对的,不过感觉很多其他读者误会了我所说的Kafka Replication,理解成整个Kafka系统都是CA系统了,哈哈。
    2. 我也学习受教了,谢谢!

    2019-05-06
    1
  • kris37
    kafka之所以说是ca系统,是因为他跟本就不保证p,因为发生了p kafka 的被独立的分区部分无法保证c 也无法保证a

    作者回复: 谢谢你的留言!仅对这个cluster的Replication而言,这个理解是正确的。

    2019-05-06
    1
  • Geek_1987v5
    CP

    作者回复: 谢谢你的留言!如果选择CP的话就要考虑到如果用户访问不到微博了会有很多不满哦。

    2019-05-06
    1
  • ykkk88
    kafka replication和放弃p有什么关系么

    作者回复: 谢谢你的提问!感觉很多读者都有同样的问题。

    我的理解是如果仅仅就一个Kafka Replication cluster来说,如果领导者挂了我们就不会再从这个cluster拿到内容了,所以在Intra-cluster Replication这个设计点上,他们是不考虑P的。

    之所以我在文中说Kafka Replication选择了CA,是因为Kafka的作者之一Jun Rao在设计Kafka Replication的时候,明确说明了“All distributed systems must make trade-offs between guaranteeing consistency, availability, and partition tolerance. Our goal was to support replication in a Kafka cluster within a single datacenter, where network partitioning is rare, so our design focuses on maintaining highly available and strongly consistent replicas.”,这一点是在Linkedin的官方文档上publish的。而在2013年的Apachecon上,Kafka Replication的技术演讲上也明确说明了“Kafka Replication: Pick CA”。

    所以你会发现,他们的设计思路是仅仅就Intra-cluster的data replication出发的。当然,如果从整个Kafka系统来说,是不可能放弃P的。

    2019-05-06
    1
  • wmg
    老师,如果kafka支持必须同步节点写成功,那是不是就是一个cp系统,如果支持非健康节点选举为leader,是不是就是ap系统?

    作者回复: 谢谢你的提问!对于整个Kafka系统来说,你的理解是正确的!

    2019-05-06
    1
收起评论
65
返回
顶部