分布式协议与算法实战
韩健
腾讯资深工程师
23193 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 31 讲
分布式协议与算法实战
15
15
1.0x
00:00/00:00
登录|注册

02 | CAP理论:分布式系统的PH试纸,用它来测酸碱度

舍弃一致性,保证可用性
舍弃可用性,保证一致性
保证可用性和分区容错性
保证一致性和分区容错性
集群对分区故障的容错能力
系统在节点间出现消息丢失或高延迟时仍能继续工作
重点在服务可用性
任何来自客户端的请求都能得到响应数据
重点在数据正确性
客户端每次读操作要读到最新写入的数据
CP模型的KV存储和AP模型的KV存储适合怎样的业务场景
课堂思考
延迟是重要指标
AP模型
CP模型
CA模型不存在
不存在网络分区时,C和A能够同时保证
AP模型
CP模型
选择一致性(C)或可用性(A)
分区容错性是必须要保证的
对指标含义做了预设和限制
证明过程由赛斯·吉尔伯特和南希·林奇完成
只能选择其中两个
一致性、可用性、分区容错性不可兼得
分区容错性
可用性
一致性
课堂思考
如何使用CAP理论
CAP不可能三角
三个指标:一致性、可用性、分区容错性
帮助解决分布式系统设计问题
用于设计合适的分区容错一致性模型
由韩健介绍
用于测酸碱度
分布式系统的PH试纸
课堂思考
内容小结
如何使用CAP理论
CAP不可能三角
CAP三指标
CAP理论

该思维导图由 AI 生成,仅供参考

你好,我是韩健。
很多同学可能都有这样的感觉,每次要开发分布式系统的时候,就会遇到一个非常棘手的问题,那就是如何根据业务特点,为系统设计合适的分区容错一致性模型,以实现集群能力。这个问题棘手在当发生分区错误时,应该如何保障系统稳定运行,不影响业务。
这和我之前经历的一件事比较像,当时,我负责自研 InfluxDB 系统的项目,接手这个项目后,我遇到的第一个问题就是,如何为单机开源版的 InfluxDB 设计分区容错一致性模型。因为 InfluxDB 有 META 和 DATA 两个节点,它们的功能和数据特点不同,所以我还需要考虑这两个逻辑单元的特点,然后分别设计分区容错一致性模型。
那个时候,我想到了 CAP 理论,并且在 CAP 理论的帮助下,成功地解决了问题。讲到这儿,你可能会问了:为什么 CAP 理论可以解决这个问题呢?
因为在我看来,CAP 理论是一个很好的思考框架,它对分布式系统的特性做了高度抽象,比如抽象成了一致性、可用性和分区容错性,并对特性间的冲突(也就是 CAP 不可能三角)做了总结。一旦掌握它,你就像拥有了引路人,自然而然就能根据业务场景的特点进行权衡,设计出适合的分区容错一致性模型。
那么问题来了:我说的一致性、可用性和分区容错性是什么呢?它们之间有什么关系?你又该如何使用 CAP 理论来思考和设计分区容错一致性模型呢?这些问题就是我们本节课所要讲的重点了。我建议你集中注意力,认真学习内容,并学以致用,把 CAP 理论应用到日常工作中。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

CAP理论是分布式系统设计中的重要理论,将分布式系统的特性抽象成一致性、可用性和分区容错性三个指标。根据CAP理论,分布式系统无法同时兼顾一致性、可用性和分区容错性,只能在这三个指标中选择两个。文章通过具体的例子和图示生动地解释了一致性、可用性和分区容错性的含义,以及它们在实际系统设计中的应用。作者还提到了CAP不可能三角,强调了在设计分布式系统时需要在三个指标中做出取舍。通过对CAP理论的介绍和解释,读者可以快速了解分布式系统设计中的重要概念和原则,为实际工作中的系统设计提供了有益的参考。文章还介绍了CP模型和AP模型的特点,以及它们在不同业务场景下的适用性。同时,作者强调了在分布式系统开发中,延迟是一个重要的指标,可以用来评估服务的可用性。总的来说,本文通过对CAP理论的深入讨论和实际案例分析,为读者提供了对分布式系统设计的全面认识和思考框架。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式协议与算法实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(69)

  • 最新
  • 精选
  • Sinclairs
    CP模型的KV存储,适合用于提供基础服务,保存少量数据,作用类似zookeeper。 AP模型的KV存储,适合查询量大的场景,不要求数据的强一致性,目前广泛应用于分布式缓存系统。 一点思考,不知道对不对?

    作者回复: 加一颗星:),能否容忍的可能的短暂的一致性延迟,是关键。

    2020-02-10
    3
    62
  • 大漠胡萝卜
    网络分区,怎么理解?

    作者回复: 网络分区是指因为网络故障导致网络不连通,不同节点分布在不同的子网络中,各个子网络内网络正常。其实,你可以这么理解,节点之间的网络通讯出现了消息丢失、高延迟的问题。

    2020-02-11
    2
    37
  • cp模型适合要求acid场景,比如银行转账。ap模型适合只要求base的场景,比如网页cdn场景,不知道理解得对不对。

    作者回复: 加一颗星:)

    2020-02-14
    28
  • enjoylearning
    还是不太明白分区容错性P和可用性A的区别,不都是随时可以提供服务吗?

    作者回复: 可以这么理解,分布式系统是必须要考虑分区容错性的,也就是说,出现分区错误时,比如节点间通讯丢消息了,系统要能运行,那么,这时候如何运行呢?是选择一致性呢,还是选择可用性呢。

    2020-02-11
    28
    22
  • iron_man
    知乎上看到的,与各位分享 一个分布式系统里面,节点组成的网络本来应该是连通的。然而可能因为一些故障,使得有些节点之间不连通了,整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。当你一个数据项只在一个节点中保存,那么分区出现后,和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。提高分区容忍性的办法就是一个数据项复制到多个节点上,那么出现分区之后,这一数据项就可能分布到各个区里。容忍性就提高了。然而,要把数据复制到多个节点,就会带来一致性的问题,就是多个节点上面的数据可能是不一致的。要保证一致,每次写操作就都要等待全部节点写成功,而这等待又会带来可用性的问题。总的来说就是,数据存在的节点越多,分区容忍性越高,但要复制更新的数据就越多,一致性就越难保证。为了保证一致性,更新所有节点数据所需要的时间就越长,可用性就会降低。 作者:邬江 链接:https://www.zhihu.com/question/54105974/answer/139037688 来源:知乎 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    作者回复: 前半部分的容忍性,其实指的的是可用性,做法是分区部署、增加数据缓存,提升可用性。分区容错性是一种行为,指的是分区错误发生时,系统依然能提高服务,这时可以提供的服务,有两种,一致性和可用性,需要注意的是,有些服务是要求一致性的,也就是说,增加集群副本数,是不能解决问题的。可用性,就比较好理解了,但在实际中,仅仅增加副本数或缓存是不够的,还需要全方位的监控能力、高灵敏的故障检测能力、全网的调度能力,等等。

    2020-02-23
    4
    19
  • zjm_tmac
    这里的节点1同步给节点2指的是日志复制还是等待节点2的事务提交完成? 如果是日志复制的话,会不会两边提交事务的时间不一致,造成读取不一致。 如果是等待事务提交的话,是不是变成了完全阻塞的,性能很低还有各种各样问题。

    作者回复: 加一颗星:)。这里是简化表示,比如你可以理解成二阶段提交的事务。关于第一个“如果”,多节点的副本是无法做到完全同时完成提交的,但能保证写完成后,读取都是一致的;如果需要实现读取的严格一致性,比如,可以通过实现“Master-Slave”模型,读写只访问Master节点,实现读取的严格一致性;第二个“如果”,就是常见事务型系统的缺点。

    2020-02-10
    2
    19
  • 霹雳大仙pp
    以阿里nacos来说,配置中心是cp,保证各节点配置强一致;注册中心是ap,保证了可用性,牺牲了强一致性。

    作者回复: 加一颗星:)

    2020-03-09
    18
  • NICK
    可不可以理解成在分布式场景下: 1. 如果业务需要强一致性,则只能牺牲可用性而选择CP模型。 2. 如果业务需要最终一致性即可,则优先满足可用性,选择AP模型?

    作者回复: 加一颗星:)

    2020-02-23
    11
  • longyi
    受限于 Raft 的强领导者模型。所有请求都在领导者节点上处理,整个集群的性能等于单机性能。这样会造成集群接入性能低下,无法支撑海量或大数据量的时序数据。 //老师,这里应该是所有的写请求都在领导者节点上处理吧? //另外,如果采用multi-raft,每个raft分片都有自己的leader,这样请求将不限于节点,而是在分片的leader上,这样性能也没那么差,老师觉得呢?

    作者回复: 加一颗星:),是写请求,相比Raft,Multi-Raft是有改进的,但和最终一致性的方案相比,还是有差距。其实,Raft不适合时序数据场景,比如,如果即使采用multi-raft,因为时序数据,有时需要拉取一批数据,这时需要在外围,再实现分布式迭代器,工作量,还是蛮大的;另外,在Raft中,uncommitted的log,可能被丢弃了,也可能在后面被提交了,也就是说,当Raft返回给客户端超时错误时,数据是否会被提交,是个不确定状态,如果这时,客户端不重试,可能会丢数据,如果客户端重试,对于没有带时间戳的时序数据,会导致数据重复,当然,我们可以通过重新约定InfluxDB行为、实现冥等操作等,来解决这个问题,但这样做,不仅增加工作量和系统复杂度,还影响用户的体验;还有最后一点,也就是最最重要的,高性能的背后,是成本,是钱,这个经济效益,会在海量数据场景,被放大,性能是最核心的一个考虑因素。

    2020-02-19
    2
    8
  • 小跑
    怎么觉得etcd-raft不是严格意义上的一致性,是线性的,只要满足大多数的情况下,哪怕个别节点挂掉,也能对外提供读写服务,所以从这个角度看,它其实一种ap模型吧。

    作者回复: Raft是具有容错能力的共识算法,可以用来实现一致性,比如,类似Google Chubby,读写操作都在领导者节点上执行。 可以这么理解,分布式事务实现的是一致性,不能容忍任何节点出问题;只要集群中有一个节点,都能继续提供服务,可以把这个理解为可用性。而Raft等共识算法,能容忍少数节点的故障,但通过读写操作都在领导者节点上执行,也能为业务提供一致性的数据服务,可以将共识算法理解为对分布式事务型算法的改进,既有容错能力,又能提供一致性。

    2020-02-14
    7
收起评论
显示
设置
留言
69
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部