cap理论_cap理论 三个特性 - CSDN
精华内容
参与话题
  • CAP 理论 —— 最通俗的解释

    千次阅读 多人点赞 2018-07-15 11:56:48
    CAP 理论是分布式系统的一个基础理论,它描述了任何一个分布式系统最多只能满足以下三个特性中的两个: 一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP 理论听起来十分...

    CAP 理论是分布式系统的一个基础理论,它描述了任何一个分布式系统最多只能满足以下三个特性中的两个:

    • 一致性(Consistency)
    • 可用性(Availability)
    • 分区容忍性(Partition tolerance)

    CAP 理论听起来十分抽象,本文尝试以生活中的例子并用通俗易懂的语言来解释 CAP 理论的含义。

    第一章:“记忆公司”面世

    一天晚上,正准备入睡时,你的妻子对你记住她生日并送她礼物表示感谢。这时,一个商业想法从你的脑海中闪现:人们总是弱于记忆生活中的事情,而我却拥有超群的记忆力,因此,为何不成立一间公司可以充分运用自己的记忆天赋来赚钱。说干就干,接着你在当地一间报社刊登了记忆公司的宣传广告:

    记忆公司 —— 你的事情永不会忘记
    还在为你老是忘记而苦恼?福音来了,只须一个电话。
    当你需要记着某件事情时,请拨打 400 - 888 - 8888,告诉我们你需要记住的事情,下次你需要找回这件事情,请再次拨打电话,我们将会告诉你的所需。
    收费: 每次只需要 10 元。

    以下是一次你和顾客的电话对话。

    • 顾客:Hey,麻烦帮我记住我邻居的生日。
    • 你:好。你邻居生日是什么时候?
    • 顾客:1月2日。
    • 你:(在一个本子,翻到这位顾客的一页,记录下他邻居的生日。)好的,已记录好。下次你找回邻居的生日,请再次拨打电话。
    • 顾客:谢谢。
    • 你:不客气,本次收费 10 元。

    第二章:业务扩大了

    随着时间的推移,记忆公司的业务发展得越来越好,越来越多的顾客打电话进来需要服务。虽然赚到的钱越来越多,但也产生了一个新的问题。
    顾客打电话进来时,需要等待的时间越来越多,另外,当你生病时,所有顾客都不能获得服务,这令人很是烦恼。
    于是,你想出了一个新的计划:

    • 你和你的妻子同时接收顾客的电话
    • 顾客仍然只需要记着一个公司的服务电话 400 - 888 - 8888
    • 一个路由器会将顾客的电话分发到你和妻子电话上

    第三章:服务出错了

    新计划实施两天后,你接到了一个名叫 John 的电话,John 是个老顾客了。

    • John:Hey
    • 你:你好,欢迎拨打记忆公司电话,有什么可以帮到你吗
    • John:可以告诉我去新泽西的航班是什么时候吗
    • 你:当然。(然后你翻开 John 的页面,发现并没有 John 航班的记录)
    • 你:你好,是不是搞错了,我们这里并没有关于你航班的信息
    • John:什么?!昨天我才刚打电话过来说去新泽西航班的事情

    哪里出错了?难道 John 撒谎了。你继续思考导致出错的原因。会不会是妻子接到了电话?你走到妻子的桌子,发现妻子将 John 的航班记录在了本子上,这时你才意识到导致问题的原因,妻子接听到 John 的电话,但你的本子没有 John 的记录。

    如果将上面的实施计划称一个分布式的设计,那这个设计存在明显的问题——一致性(consistent)的问题。打进来的电话可能其中一人接听并记录下来,下次电话查询时却可能由另一人接听,这样就会出现不一致的问题,无法为顾客准确提供服务。

    第四章:解决一致性问题

    晚上你在床上翻来覆去,最后想到一个解决一致性问题的办法,你把新的计划告诉妻子:

    • 每次接收记录的电话(顾客要求帮忙记住他们的事情)时,我们同时告知另一个人
    • 这样,我们两个人都会在本子更新这位顾客的记录
    • 下次这位顾客再次打电话进来查询,这时我们不需要告知对方,因为两个本子都有这位顾客的记录了

    这个方法只有一个问题,你告诉妻子,当有顾客需要记录时,我们不能并行地工作。例如,你接收到记录的电话并这个信息告知我,这时我就不能再接听其他顾客的电话了。但这个问题基本上也是可以接受的,因为大部分顾客的电话都是查询的。

    老公你真聪明,妻子称赞你,但这个设计还有一个问题。如果某天我们其中一个人有事不能工作了怎么办?由于我们要求每次接到记录电话需要同时更新两个本子,这就导致我们不能为顾客提供记录的服务,这样就导致无法满足 可用性(availability)的要求。例如,当我接到一个记录的电话时,而你恰好不在,这样我就无法完成这个顾客的服务。这是由于我无法要求你更新你的本子。

    第五章:更好的办法

    这时你才意识到,设计一个分布式的系统是多么的不容易,难道就没有同时满足 一致性和可用性 的设计吗?
    又经过一晚的思考,你想到一个两全其美的办法,新的办法跟之前的很相似。你把新的办法告诉妻子:

    • 当接到记录的电话(顾客要求为他们记录事情),如果我们两人当天都上班,那么我们同时记录下这位顾客的记录
    • 但如果另一人当天没上班,我们可以将记录通过 E-mail 的方式发送给不上班的人
    • 第二天,没上班的人上班后第一件事就是接收所有的 E-mail ,并在自己的本子上记录所有顾客的要求。记录好后,才开始接收第一个电话。

    真是天才,妻子说,这个办法我找不出任何问题了,而且可以同时满足 一致性和可用性 的要求。

    第六章:妻子生气了

    公司所有业务继续正常运作了好一段时间,即使你和妻子其中一人不上班,服务仍然可以正常提供。
    好景不长,新的问题又出现了。
    一天,妻子由于某件小事对你很是生气,以至于她接到一位顾客需要记录的电话并没告知你。由于记录没能在两个本子更新,你的设计完全被打破了。你的设计建立在两人良好沟通的前提下,如果出现沟通无法进行的情况,系统就出现问题了。也就是说,你的设计没有达到 分区容忍性(partition tolerant)的要求。
    当然,你也可以允许沟通无法进行的情况下继续提供服务。这样,当有顾客需要记录时,由于需要满足 一致性 要求,这位顾客的服务就无法完成,也就是 可用性 无法满足。。。

    第七章:结论

    让我们再次回到 CAP 理论,CAP 理论告诉我们,当设计一个分布式系统时,我们无法同时满足 一致性,可用性,分区容忍性 的要求,我们最多满足其中的两个要求,形式化的证明,可以参考 CAP 理论的证明

    • 一致性:一旦顾客更新了记录,下次再打电话查询时,总能获取最新的记录
    • 可用性:只要你和妻子有人上班,记忆公司总能为顾客提供服务
    • 分区容忍性:即使你和妻子的沟通无法进行,记忆公司仍然可以提供服务

    番外篇:背后的记录员

    上面设计的系统仍然有优化的空间。记忆公司可以雇佣一个记录员,当你和妻子其中一人接到顾客的记录电话时,记录员在背后会将这个记录写在另一个人的本子上。这样一来,另一个人的服务就不会被这个记录的电话打断。许多 NoSQL 系统就使用了这个方法,一个节点更新了数据,背后会有一个进程将数据同步到其他节点。
    这种设计存在的问题是可能在短时间内丢失一致性。例如,顾客打电话进来要求记录,妻子接听到这个电话。紧接着,这位顾客再次打电话进来要求查询,你接听到这个查询的电话。如果记录员还没将这位顾客的记录更新到你的本子,这时顾客就没法正常查询。虽然存在这种可能性,但你也不用过分担心,因为顾客很少会打完记录电话后马上又打查询电话,所以出现本子内容不一致的概率很低。

    参考资料

    1. http://ksat.me/a-plain-english-introduction-to-cap-theorem/
    2. http://robertgreiner.com/2014/08/cap-theorem-revisited/
    3. https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/
    展开全文
  • 在此之前我就隐约对文中提到的一些 CAP 误解嗤之以鼻,这篇文章让我更加确信了之前零碎的认知,不夸张地讲,这应该是我看过的最通俗也是最深刻的 CAP 科普文。 在 Jeff Hodges 精彩的博客文章给年轻人关于分布式...

    本文转自 51CTO技术栈 https://mp.weixin.qq.com/s/6PgqyigrgVICl0JiI73oNg

    在此之前我就隐约对文中提到的一些 CAP 误解嗤之以鼻,这篇文章让我更加确信了之前零碎的认知,不夸张地讲,这应该是我看过的最通俗也是最深刻的 CAP 科普文。

     

    在 Jeff Hodges 精彩的博客文章给年轻人关于分布式系统的笔记中,他建议我们用 CAP 定理来评论系统。

     

    很多人都听取了这个建议,描述他们的系统为"CP" (有一致性但在网络分区的时候不可用),“AP”(可用但是在网络分区的时候不一致) 或者有时候 "CA" (说明"我还没有读过 Coda 的五年前的文章")。

     

    我同意 Jeff 的所有观点,唯独他关于 CAP 定理的观点,我必须表示不同意。

     

    CAP 定理本身太简单化而且被广泛的误解,以至于在描述系统上没有太多用处。

     

    因此我请求我们不要再引用 CAP 定理,不要再讨论 CAP 定理。取而代之,我们应该用更精确的术语来理解我们系统的权衡。

     

    PS:没错,我意识到很讽刺的是我不希望别人再讨论这个话题,但我却正在分享一篇关于这个话题的博客文章。

     

    但是至少这样以后别人问我为什么不喜欢讨论 CAP 定理的时候,我可以把这篇文章的链接给他。还有,抱歉这篇文章有些吐槽,但是至少这个吐槽有文献引用。

     

    CAP 用的是非常精确的定义

     

    如果你想引用 CAP 作为一个定理(而不是一个模糊的,用来做数据库市场营销的概念),你需要用非常精确的定义。

     

    数学要求精确,只有当你的用词和定理的证明中的定义是一样的时候,这个证明才有意义。

    CAP 的证明用的是非常具体的定义:

    • 一致性(Consistency在 CAP 中是可线性化的意思(linearizability)。而这个是非常特殊(而且非常强)的一致性。

      尤其是虽然 ACID 中的 C 也是一致性(Consistency),但是和这里的一致性没有任何关系。我会在后面解释可线性化是什么意思。

    • 可用性(Availability在 CAP 中是定义为"每一个请求(request)如果被一个工作中的[数据库]节点收到,那一定要返回[非错误]的结果"。

      注意到,这里一部分节点可以处理这个请求是不充分的。任意一个工作中的节点都要可以处理这个请求。所以很多自称"高度可用"的系统通常并没有满足这里的可用性的定义。

    • 分区容错(Partition Tolerance基本上就是说通信是在异步的网络中。信息是可能延迟送达或者被丢失的。互联网还有我们所有的数据中心都有这个属性。所以我们在这件事上并没有选择。

     

    还有就是注意到 CAP 并没有描述任意一个老的系统,而是一个非常特殊的系统:

    • CAP 系统的模型是一个只能读写单个数据的寄存器。这就是全部。CAP 没有提到任何关于关系到多个事物(Object)的事务(Transaction)。

      他们根本就不在这个定理的范围之内,除非你可以把这些问题约化到一个单个寄存器的问题。

    • CAP 定理只考虑了网络分区这一种故障情况(比如节点们还在运行,但是他们之间的网络已经不工作了)。这种故障绝对会发生,但是这不是唯一会出故障的地方。

      节点可以整个崩溃(Crash)或者重启,你可能没有足够的磁盘空间,你可能会遇到一个软件故障(Bug),等等。

      在建分布式系统的时候,你需要考虑到更多得多的问题。如果太关注 CAP 就容易导致忽略了其他重要的问题。

    • 还有 CAP 根本没有提到延迟(Latency而常常人们其实对关心延迟比可用性更多。

      事实上,满足 CAP 可用性的系统可以花任意长的时间来回复一个请求,而且同时保持可用性这个属性。

      我来冒险说一句,我猜如果你的系统要花两分钟来加载一个页面,你的用户是不会称它是“可用的”。

     

    如果你的用词是符合 CAP 证明中的精确定义的,那么它对你来说是适用的。但是如果你的一致性还有可用性是有其他意思的,那么你不能期待 CAP 对你还是适用的。

     

    当然,这并不意味着你通过重新定义一些词汇就可以做到一些不可能的事情!这只是说你不能靠 CAP 来给你提供指导方向,而且你不能通过 CAP 来为你的观点来辩解。

     

    如果 CAP 定理不适用,那么这就意味着你必须自己来考虑取舍。你必须根据你自己对一致性还有可用性的定义来思考这些属性,而且你能证明自己的定理就更好了。但是请不要称它为 CAP 定理,因为这个名字已经被用了。

     

    可线性化

    如果你对可线性化不是很熟悉(也就是 CAP 中的一致性),那么让我来简短地解释一下。

     

    正式的定义不是特别直观,但是关键的思想用非正式的描述就是:

    如果 B 操作在成功完成 A 操作之后,那么整个系统对 B 操作来说必须表现为 A 操作已经完成了或者更新的状态。

     

    为了可以解释的更清楚一些,让我们来看一个例子。在这个例子中的系统并不是可线性化的。

     

    看下面这个图:

     

    这张图展示了 Alice 还有 Bob, 他们在同一个房间,都在用他们的手机查询 2014 年世界杯的决赛结果。

     

    就在最终结果刚发布之后,Alice 刷新了页面,看到了宣布冠军的消息,而且很兴奋地告诉了 Bob。

     

    Bob 马上也重新加载了他手机上的页面,但是他的请求被送到了一个数据库的拷贝,还没有拿到最新的数据,结果他的手机上显示决赛还正在进行。

     

    如果 Alice 和 Bob 同时刷新,拿到了不一样的结果,并不会太让人意外。因为他们不知道具体服务器到底是先处理了他们中哪一个请求。

     

    但是 Bob 知道他刷新页面是在 Alice 告诉了他最终结果之后的。所以他预期他查询的结果一定比 Alice 的更新。事实是,他却拿到了旧的结果。这就违反了可线性化。

     

    只有 Bob 通过另外一个沟通渠道从 Alice 那里知道了结果, Bob 才能知道他的请求一定在 Alice 之后。

     

    如果 Bob 没有从 Alice 那里听到比赛已经结束了,他就不会知道他看到的结果是旧的。

     

    如果你在建一个数据库,你不知道用户们会有什么另外的沟通渠道。所以,如果你想提供可线性化(CAP 的一致性),你就需要让你的数据库看起来就好像只有一个拷贝,虽然实际上可能有多个备份在多个地方。

     

    这是一个非常昂贵的属性,因为它要求你做很多协调工作。甚至你电脑上的 CPU 都不提供本地内存的可线性化访问!

     

    在现代的 CPU 上,你需要用 Memory Barrier 指令来达到可线性化访问。甚至测试一个系统是不是可线性化的也是很困难的。

     

    CAP 可用性

     

    让我们来简短的讨论一下为什么在网络分区的情况下,我们要放弃可用性和一致性中的一个。

     

    举个例子,你的数据库有两个拷贝在两个不同的数据中心。具体怎么做备份并不重要,可以是 Single-Master,或者多个 Leader,或者基于 Quorum 的备份(Dynamo 使用的方式)。

     

    要求是当数据被写到一个数据中心的时候,他也一定要被写到另一个数据中心。

     

    假设 Client 只连接到其中一个数据中心,而且连接两个数据中心的网络故障了。

     

    那么现在假设网络中断了,这就是我们所说的网络分区的意思。接下来怎么样呢?

     

    显然你有两个选择:

    • 你的应用还是被允许写到数据库,所以两边的数据库还是完全可用的。但是一旦两个数据库之间的网络中断了,任何一个数据中心的写操作就不会在另一个数据中心出现。

      这就违反了可线性化(用之前的例子,Alice 可能链接到了一号数据中心,而 Bob 连接到了二号数据中心)。

    • 如果你不想失去可线性化,你就必须保证你的读写操作都在同一个数据中心,你可能叫它 Leader。

      另一个数据中心,因为网络故障不能被更新,就必须停止接收读写操作,直到网络恢复,两边数据库又同步了之后。

      所以虽然非 Leader 的数据库在正常运行着,但是他却不能处理请求,这就违反了 CAP 的可用性定义。

     

    而这个,其实就是 CAP 定理的证明。这就是全部了。这里的例子用到了两个数据中心,但是对于一个数据中心内的网络故障也是同样适用的。我只是觉得用两个数据中心这样更容易考虑这个问题。

     

    注意到上面第二点,就算它违反了 CAP 的可用性,但我们还是在成功地处理着请求。

     

    所以当一个系统选择了可线性化(也就是说不是 CAP 可用的),这并不一定意味着网络分区一定会造成应用停运。

     

    如果你可以把用户的流量转移到 Leader 数据库,那么用户根本就不会注意到任何问题。

     

    实际应用中的可用性和 CAP 可用性并不相同。你应用的可用性多数是通过 SLA 来衡量的(比如 99.9% 的正确的请求一定要在一秒钟之内返回成功)。

     

    但是一个系统无论是否满足 CAP 可用性其实都可以满足这样的 SLA。实际操作中,跨多个数据中心的系统经常是通过异步备份(Asynchronous Replication)的,所以不是可线性化的。

     

    但是做出这个选择的原因经常是因为远距离网络的延迟,而不是仅仅为了处理数据中心的网络故障。

     

    很多系统既不是可线性化的也不是 CAP 可用的

     

    在 CAP 对可用性还有一致性严格的定义下,系统们表现怎么样?

     

    拿任意一个 Single Master 的有备份的数据库作为一个例子。这也是标准的数据库设置。

     

    在这种情况下,如果用户不能访问 Leader,就不能写到数据库。虽然他还能从 Follower 那里读到数据,但是他不能写任何数据就说明它不是 CAP 可用的。更不要说这种设置还常常声称自己是“高可用的(High Availablity)”。

     

    如果以上这种设置不是 CAP 可用的,那是不是就是说他满足 CP(一致)?

     

    等一下,如果你是从 Follower 那里读到的数据,因为备份是异步的,所以你可能读到旧的数据。所以你的读操作不是可线性化的,所以不满足 CAP 中的一致性。

     

    而且支持 Snapshot Isolation/MVCC 的数据库是故意做成不可线性化的。否则会降低数据库的并发性。

     

    比如 PostgreSQL 的 SSI 提供的是可串行化而不是可线性化,Oracle 两者都不支持。仅仅因为数据库标榜自己是 ACID 并不意味着它就满足 CAP 中的一致性。

     

    所以这些系统既不是 CAP 一致的,也不是 CAP 可用的。他们既不是 CP 也不是 AP,他们只是 P,不管这是什么意思。(是的,“三选二”也允许你只从三个中选一个,甚至一个都不选!)

     

    那 NoSQL 怎么样的?拿 MongoDB 作为一个例子:每一个 Shard 都只有一个 Leader(至少只要他不在 split-brain 的模式下,它应该是这样的),根据以上的论证,那就说明他不是 CAP 可用的。

     

    而且 Kyle 最近发现,设置了最强的一致性,他还是允许非一致性的读操作,所以它也不是 CAP 一致的。

     

    那像 Riak,Cassandra 还有 Voldemort 这些声称是 AP 的高可用的 Dynamo 的继承者们又怎么样呢?

     

    这取决于你的设置。如果你接受读写只访问一个拷贝(R=W=1),那么这确实是 CAP 可用的。

     

    但是如果你要求 Quorum 读写(R+W>N),而且你有网络分区,那么那些被分在少部分节点的用户就不能达到 Quorum。

     

    所以 Quorum 操作不是 CAP 可用的(至少暂时是不可用的,直到你在少部分的分区内加入了更多的节点)。

     

    你有时候会看到人们声称 Quorum 读写可以保证可线性化,但是我觉得依赖这样的声明是不明智的。

     

    因为在一些复杂的情况下,Read Repair 操作和 Sloppy Quorum 同时发生,就有可能会重写已经被删除了的数据。

     

    或者当备份数(Replicas)已经低于原来的 W 值(违反了 Quorum 的条件),或者当备份数被加到了高于原来的 N 值(还是违反了 Quorum 的条件),这些都可以导致不可线性化的访问结果。

     

    这些都不是差的系统:他们在实际运用中都很成功。但是目前为止,我们还是不能严格把他们分类为 AP 或者 CP,要么是因为取决于具体的设定,或者是因为这个系统一致性和可用性都不满足。

     

    案例分析:ZooKeeper

     

    那 ZooKeeper 又怎么样呢?他用了 Consensus 算法,所以人们一般认为他是很清楚的选择了一致性而放弃了可用性(也就是 CP 系统)。

     

    但是如果你阅读 ZooKeeper 的文档,他们很清楚的说了 ZooKeeper 的默认设置不提供可线性化的读操作。

     

    每一个连接到一个服务器的客户端,当你要读的时候,即使别的节点有更新的数据,你只能看到那个服务器本地的数据。

     

    这样读操作就比需要收集 Quorum 或者访问 Leader 要更快。但这也说明 ZooKeeper 默认不满足 CAP 的一致性定义。

     

    做可线性化的读操作在 ZooKeeper 中是支持的。你需要在读操作之前发一个 Sync 命令。

     

    但这不是默认的设置,因为这样读操作会更慢。人们有时候会用 Sync 命令,但一般不会是所有的读操作都用。

     

    那 ZooKeeper 的可用性呢?他要求达到大多数 Quorum,来达到共识,才能处理一个写操作。

     

    如果你有网络分区,一边有大多数节点,一边有少部分节点。那么拥有大多数节点的分区还可以继续工作,但是少部分节点的分区就算节点们都正常工作着,还是不能处理写操作。

     

    所以 ZooKeeper 的写操作在网络分区的情况下,不满足 CAP 的可用性(即使拥有大多数节点的分区还是可以处理写操作的)。

     

    更有意思的是,ZooKeeper 3.4.0 还加入了一个只读的模式。在这个模式下,少部分节点的分区还可以继续处理读操作,不需要 Quorum! 

     

    这个读操作是满足 CAP 可用性的。所以 ZooKeeper 默认设置既不是一致的(CP)也不是可用的(AP),只是"P"。

     

    但是你有选择通过用 Sync 命令来让它成为 CP。并且在正确的设置下,读操作(不包括写)其实是 CAP 可用的。

     

    这让人不是很舒服。如果就因为 ZooKeeper 的默认设置不是可线性化的就称他为不一致,那就歪曲了他的功能。

     

    他其实可以提供非常强的一致性!他支持 Atomic Broadcast(这个可以约化为共识问题)以及每个 Session 的 Causal Consistency。

     

    这比 read your writes,monotonic reads 还有 consistent prefix reads 在一起都要强。

     

    他的文档上说 ZooKeeper 提供可串行化的一致性,但这其实是过于谦虚了,因为他其实可以提供更强的一致性。

     

    根据 ZooKeeper 的例子,你就会发现就算这系统在网络分区的时候既不是 CP 也不是 AP(甚至在默认设置下,就算没有网络分区,也不是可线性化的),但他还是很合理的。

     

    我猜 ZK 在 Abadi 的 PACELC 的框架下是 PC/EL,但我不觉得这比 CAP 更有启发性。

     

    CP/AP:一个伪二分法

     

    事实上我们都没有成功地把一个数据库无歧义地分类为 AP 或者 CP。这应该告诉我们 CP/AP 根本就不是合适的用来描述系统的标签。

     

    我相信我们应该不要再把数据库归类为 AP 或者 CP 了,因为:

    • 在同一个软件内,你可能有多个一致性属性的选择。

    • 很多系统在 CAP 的定义下,既不是一致也不可用。然而我从来没有听到别人称这些系统为"P",可能是因为这样不太好看。但这并不差,他很可能是完全合理的设计,他只是不在 CP/AP 这两个分类中。

    • 虽然大部分软件都不在 CP/AP 这两类中,但人们还是强行把软件分为这两类。这就导致了,为了适用,不可避免地改变对“一致性”或者“可用性”的定义。

      不幸的是,如果用词的定义改变了,CAP 定理自己也不适用了,那 CP/AP 区分也就完全没有意义了。

    • 把系统分为这两类,导致了很多细节被忽略。在考虑分布式系统设计的时候,会有很多关于容错,延迟,简单模型,运行成本,等等的考虑。把那么多细节编码到一个比特的信息,显然是不可能的。

      比如说虽然 ZooKeeper 有一个 AP 的只读模式,但这个模式也提供对所有写操作的 total ordering。

      这比 Riak 或者 Cassandra 这些 AP 系统提供的保障要强得多。所以简单地把他们都归为 AP 一个类别就显得很不合理。

    • 甚至 Eric Brewer 承认 CAP 是一个容易误导人的而且过于简化的模型。在 2000 年,CAP 的意义在于让大家开始讨论关于分布式系统的取舍。

      他在这方面做得很好,但是他不是用来作为一个正式的突破性的结果,也不是一个严格的数据系统的分类方式。

      15 年之后,我们已经有了多得多的有不一样一致性和容错模型的系统。CAP 已经完成了他自己的使命,现在是时候不要在纠结了。

     

    学会独立思考

     

    如果用 CP 和 AP 来描述和评论系统是不合适的,那么我们应该用什么呢?我不认为有一个唯一的答案。

     

    很多人花了很多心思考虑这些问题,也提出了术语和模型来帮助我们理解这些问题。

     

    想要学习这些思想,你就需要更深入自己阅读文献:

    • 一个很好的起点就是 Doug Terry 的论文。其中他用棒球来解释了各种不一样的最终一致性。可读性很强,而且就算对像我这样不是美国人而且完全不懂棒球也解释的很清晰。

    • 如果你对 Transaction 的 Isolation 模型有兴趣(这和分布式系统的一致性不一样,但是相关),我的小项目 Hermitage 你可以看一下。

    • 这篇论文讨论了分布式系统的一致性和 Transaction 的 Isolation 以及可用性之间的关系。(这篇论文也描述了不同一致性之间的分级。Kyle Kingsbury 很喜欢给别人讲这个。)

    • 当你读到过这些了以后,你应该已经准备好深入阅读论文。我在这篇文章中加入了很多对文献的引用。去看一下,很多专家已经帮你把很多问题都已经解决了。

    • 作为最后的手段,如果你不想读论文原文,我建议你看一下我的书。这本书用通俗易懂的方式总结了大多数重要的思想。

    • 如果你想学更多关于怎么正确使用 ZooKeeper,Flavio Junqueira 还有 Benjamin Reed 的书是非常不错的。

     

    不管你选择哪一种学习方式,我都鼓励你保持好奇心和耐心,因为这不是容易的学科。

     

    但是这是有回报的,因为你学会如果考虑取舍,进而搞清楚什么样的架构对于你的应用是最合适的。

     

    但是不管你做什么,请不要再说 CP 还有 AP 了,因为根本不合理。

     

    最后,谢谢 Kyle Kingsbury 还有 Camille Fournier 对于这篇文章初稿的评论。当然,所有的错误还有不受欢迎的观点都是我本人的。

    出处:https://blog.the-pans.com/cap/

    展开全文
  • CAP原则(CAP定理)、BASE理论

    千次阅读 2018-06-11 17:30:12
    CAP是Consistency、Availablity和Partition-tolerance的缩写。分别是指:1.一致性(Consistency):每次读操作都能保证返回的是最新数据;2.可用性(Availablity):任何一个没有发生故障的节点,会在...CAP理论指...

    CAP是Consistency、Availablity和Partition-tolerance的缩写。分别是指:

    1.一致性(Consistency):每次读操作都能保证返回的是最新数据;

    2.可用性(Availablity):任何一个没有发生故障的节点,会在合理的时间内返回一个正常的结果;

    3.分区容忍性(Partition-torlerance):当节点间出现网络分区,照样可以提供服务。

    CAP理论指出:CAP三者只能取其二,不可兼得。其实这一点很好理解:

    首先,单机都只能保证CP

    有两个或以上节点时,当网络分区发生时,集群中两个节点不能相互通信(也就是说不能保证可用性A)。此时如果保证数据的一致性C,那么必然会有一个节点被标记为不可用的状态,违反了可用性A的要求,只能保证CP。

    >反正,如果保证可用性A,即两个节点可以继续各自处理请求,那么由于网络不通不能同步数据,必然又会导致数据的不一致,只能保证AP。


    一、单实例

    单机系统和显然,只能保证CP,牺牲了可用性A。单机版的MySQL,Redis,MongoDB等数据库都是这种模式。


    实际中,我们需要一套可用性高的系统,即使部分机器挂掉之后仍然可以继续提供服务。

    二、多副本


    相比于单实例,这里多了一个节点去备份数据。

    对于读操作来说,因为可以访问两个节点中的任意一个,所以可用性提升。

    对于写操作来说,根据更新策略分为三种情况:

    1.同步更新:即写操作需要等待两个节点都更新成功才返回。这样的话如果一旦发生网络分区故障,写操作便不可用,牺牲了A。

    2.异步更新:即写操作直接返回,不需要等待节点更新成功,节点异步地去更新数据(FastDFS文件系统的存储节点就是用这种方式,写完一份数据之后立即返回结果,副本数据由同步线程写入其他同group的节点)。这种方式,牺牲了C来保证A,即无法保证数据是否更新成功,还有可能会由于网络故障等原因,导致数据不一致。

    3.折衷:更新部分节点成功后便返回。

    这里,先介绍一下类Dynamo系统用于控制分布式存储系统中的一致性级别的策略--NWR:

    *N:同一份数据的副本个数

    *W:写操作需要确保成功的副本个数

    *R:读操作需要读取的副本个数

    当W+R>N时,由于读写操作覆盖到的副本集肯定会有交集,读操作只要比较副本集数据的修改时间或者版本号即可选出最新的,所以系统是强一致性的;反之,当W+R<=N时是弱一致性的。

    如:(N,W,R)=(1,1,1)为单机系统,是强一致性的;(N,W,R)=(2,1,1)位常见的master-slave模式,是弱一致性的。


    举例:

    > 如像Cassandra中的折衷型方案QUORUM,只要超过半数的节点更新成功便返回,读取时返回多副本的一致的值。然后,对于不一致的副本,可以通过read repair的方式解决。read repair:读取某条数据时,查询所有副本中的这条数据,比较数据与大多数副本的最新数据是否一致,若否,则进行一致性修复。其中,W + R > N,故而是强一致性的。

    > 又如Redis的master-slave模式,更新成功一个节点即返回,其他节点异步去备份数据。这种方式只保证了最终一致性最终一致性:相比于数据时刻保持一致的强一致性,最终一致性允许某段时间内数据不一致。但是随着时间的增长,数据最终会到达一致的状态。其中,W+R<N,所以只能保证最终一致性。

    此外,N越大,数据可靠性越好,但是由于W或者R越大,读写开销越大,性能越差,所以一般需要总和考虑一致性,可用性和读写性能,设置W,R都为N/2+1。

    其实,折衷方案和异步更新的方式从本质上来说是一样的,都是损失一定的C来换取A的提高。而且,会产生'脑裂'的问题--即网络分区时节点各自处理请求,无法同步数据,当网络恢复时,导致不一致。

    一般的,数据库都会提供分区恢复的解决方案:

    1.从源头解决:如设定节点通信的超时时间,超时后'少数派'节点不提供服务。这样便不会出现数据不一致的情况,不过可用性降低。

    2.从恢复解决:如在通信恢复时,对不同节点的数据进行比较、合并,这样可用性得到了保证。但是在恢复完成之前,数据是不一致的,而且可能出现数数据冲突。

    光这样还不够,当数据量较大时,由于一台机器的资源有限并不能容纳所有的数据,我们会向把数据分到好几台机器上存储。


    三、分片


    相比于单实例,这里多了一个节点去分割数据。

    由于所有数据只有一份,一致性得以保证;节点间不需要通信,分区容忍性也有。

    然而,当任意一个节点挂掉,丢失了一部分的数据,系统可用性得不到保证。

    综上,这和单机版的方案一样,都只能保证CP。

    那么,有哪些好处呢?

    1.某个节点挂掉只会影响部分服务,即服务降级;

    2.由于分片了数据,可以均衡负载;

    3.数据量增大/减小后可以相应的扩容/缩容。

    大多数的数据库服务都提供了分片的功能。如Redis的slots,Cassandra的patitions,MongoDB的shards等。


    基于分片解决了数据量大的问题,可是我们还是希望我们的系统是高可用的,那么,如何牺牲一定的一致性去保证可用性呢?


    四、集群


    可以看到,上面这种方式综合了前两种方式。同上分析,采用不同的数据同步策略,系统CAP保证各有不同。不过,一般数据库系统都会提供可选的配置,我们根据不同的场景选择不同的特性。

    其实,对于大多数的非金融类互联网公司,要求并非强一致性,而是可用性和最终一致性的保证。这也是NoSQL流行于互联网应用的一大原因,相比于强一致性系统的ACID原则,它更加倾向于BASE:

    >Basically Available:基本可用性,即允许分区失败,除了问题仅服务降级;

    >Soft-state:软状态,即允许异步;

    >Eventual Consistency:最终一致性,允许数据最终一致性,而不是时刻一直。


    五、总结

    基本上,上面讨论的几种方式已经涵盖了大多数的分布式存储系统了。我们可以看到,这些个方案总是需要通过牺牲一部分去换取另一部分,总没法达到100%的CAP。选择哪种方案,依据就是在特定场景下,究竟哪些特性是更加重要的了。


    转自:https://blog.csdn.net/lavorange/article/details/52489998
    展开全文
  • CAP理论

    万次阅读 多人点赞 2014-06-16 09:10:22
    CAP理论在中国有着广泛的知名度,

    CAP理论在互联网界有着广泛的知名度,知识稍微宽泛一点的工程师都会把其作为衡量系统设计的准则。大家都非常清楚地理解了CAP:任何分布式系统在可用性、一致性、分区容错性方面,不能兼得,最多只能得其二,因此,任何分布式系统的设计只是在三者中的不同取舍而已。

    事实上,让人吃惊的是,CAP在国外的响力完全不如所想,相反还伴随着诸多的争论。下面我们系统地阐述一下CAP的来龙去脉。

    1.CAP的历史

    1985年Lynch证明了异步通信中不存在任何一致性的分布式算法(FLP Impossibility)的同时,人们就开始寻找分布式系统设计的各种因素。一致性算法既然不存在,但若能找到一些设计因素,并进行适当的取舍以最大限度满足实现系统需求成为当时的重要议题。比如,在CAP之前研究者就已经发现低延迟和顺序一致性不可能同时被满足【8】。
    2000年,Eric Brewer教授在PODC的研讨会上提出了一个猜想:一致性、可用性和分区容错性三者无法在分布式系统中被同时满足,并且最多只能满足其中两个!
    这个猜想首次把一致性、可用性和分区容错三个因素提炼出来作为系统设计的重要特征,断言用此三者可以划分所有的分布式系统,并指明这三个特征之间的不可能性关系。Brewer猜想比单纯的“低延迟和顺序一致性不能被同时满足”的结论更具体,对实际系统的构建也更具有可操作性!
    Brewer教授当时想象的分布式场景是webservice,一组websevrice后台运行着众多的server,对service的读写会反应到后台的server集群,并对CAP进行了定义:
    • C(一致性):所有的节点上的数据时刻保持同步
    • A(可用性):每个请求都能接受到一个响应,无论响应成功或失败
    • P(分区容错):系统应该能持续提供服务,即使系统内部有消息丢失(分区)
    高可用、数据一致是很多系统设计的目标,但是分区又是不可避免的事情:
    • CA without P:如果不要求P(不允许分区),则C(强一致性)和A(可用性)是可以保证的。但其实分区不是你想不想的问题,而是始终会存在,因此CA的系统更多的是允许分区后各子系统依然保持CA。
    • CP without A:如果不要求A(可用),相当于每个请求都需要在Server之间强一致,而P(分区)会导致同步时间无限延长,如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
    • AP wihtout C:要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。
    CAP的出现仿佛是一盏明灯,它揭露了分布式系统的本质,并给出了设计的准则,而这正是1985年以来人们正在寻找的东西!所以CAP在当时的影响力是非常大的!

    2. CAP被上升为定理

    2002年,Lynch与其他人证明了Brewer猜想,从而把CAP上升为一个定理【2】。但是,她只是证明了CAP三者不可能同时满足,并没有证明任意二者都可满足的问题,所以,该证明被认为是一个收窄的结果。
    Lynch的证明相对比较简单:采用反正法,如果三者可同时满足,则因为允许P的存在,一定存在Server之间的丢包,如此则不能保证C,证明简洁而严谨。
    在该证明中,对CAP的定义进行了更明确的声明【2】:
    • C:一致性被称为原子对象,任何的读写都应该看起来是“原子“的,或串行的。写后面的读一定能读到前面写的内容。所有的读写请求都好像被全局排序。
    • A:对任何非失败节点都应该在有限时间内给出请求的回应。(请求的可终止性)
    • P:允许节点之间丢失任意多的消息,当网络分区发生时,节点之间的消息可能会完全丢失
    该定义比Brewer提出的概念清晰了很多,也显得更加正式化!

    3.前所未有的质疑

    当国内工程师对CAP痴迷的时候,国外的工程师和研究者对CAP提出了各种质疑,纷纷有用反例证明着CAP在各种场合不适用性,同时挑战着Lynch的证明结果!
    纵观这些质疑,基本都是拿着一个非常具体的系统,用CAP的理论去套,最后发现要么CAP不能Cover所有的场景,要么是CAP的定义非常模糊,导致自相矛盾!一句话,把CAP接地气是非常困难的!
    你是否看了CAP的概念定义后还是感觉很模糊?如果是,你并不孤独,有很多人都是如此!
    CAP没有考虑不同的基础架构、不同的应用场景、不同的网络基础和用户需求,而C、A、P在这些不同场景中的含义可能完全不同,这种无视差异化的定义导致了非常大的概念模糊,同时也变成CAP被质疑的源头!

    3.1 质疑1:概念混乱,废话一堆,不能作为定理

    在论文【4】中,作者对CAP发起了强烈的挑战,强烈谴责了CAP模糊不一致的概念:
    1. 在CA中的C代表的是本地一致性;CP中的代表的是全局一致性,AP中直接没有C;这些C的含义在不同的场景根本就不同
    2. 终端用户agent该不该引入到CAP中?CAP到底是说一个agent的多次更新,还是多个用户的一次更新?没有agent参与的系统谈什么一致性?
    3. 如果分区发生在系统内部(水平分区),对agent而已并没有影响;若分区发生在agent与系统间(垂直分区),这种情况对DNS系统架构的可用性根本没有任何影响;但对银行事务架构却有巨大影响。也就是说,可用性、分区容错,是两个相关切无法独立切分的概念
    一句话:CAP说了一些永远不存在的废话!作为一个严格的数学定理,一定要概念清晰并且可自证明,CAP显然不具备这个条件,并声称“绝不承认其为一个定理”!
    【4】的作者对相对论有相当的理解,从相对论来看,每个节点都只知道自己的结果,永远无法得知其他节点的情况,系统整体是否一致我怎么会知道?
    并且作者对一致性、可用性归结为一个非常深刻的见解:一切都是时间视图!多长时间返回结果算可用?多长时间返回认为不可用?多长时间数据同步算一致?因此,一切的本质是时间!
    根据时间特性和相对论,作者提出了一个独创的promise系统模型,每个节点都对自己的行为在有限时间内进行承诺,其他节点根据这个承诺和自己的状态决定本地如何处理。。。
    作者还上传了自己的笔记拍照,我大体看了下,基本上是构建了一个基于时间同步的有限状态机,实际上Lynch早就证明,在同步环境的一致性是可以达到的!

    3.2 质疑2:不适用于数据库事务架构

    【6】的作者,把详细地列举了分布式事务中可能的分区情况,比如说应用因为更新一些错误的数据而导致失败,此时无论使用什么样的高可用方案都是徒劳,因为数据发生了无法修正错误!作者还列举了其他一些情况,虽然分区发生但无法保持高可用。这就说明了CAP并不能不被用来完全解释数据库事务架构!
    作者还建议,应该放弃分区容错,因为在局域网中分区很少发生;而在广域网中,有各种备选方案,导致实际上的分区也较少发生。

    3.3 质疑3:应该构建不可变模型避免CAP的复杂性

    【7】的文章标题就是锤死CAP,作者对CAP的不屑溢于言表!
    作者认为CAP的困境在于允许数据变更,每次变更就得数据同步,保持一致性,这样系统非常复杂。
    他认为数据就是客观存在的,不可变,只能增、查。传统的CURD变为CR。这个概念非常类似Cassandra中的顺序写的概念,任何的变更都是增加记录。通过对所有记录的操作进行合并,从而得到最终记录。
    因此,作者认为任何的数据模型都应该抽象为:Query=Function(all data),任何的数据试图都是查询,查询是对全体数据施加了某个函数的结果。这个定义清晰简单,完全抛弃了CAP那些繁琐而又模糊的语义。因为每次操作都是队所有数据进行全局计算,也就没有了一致性问题!
    有这样的系统吗?有,Hadoop便是!作者认为,Hadoop的HDFS只支持数据增加,而Mapeduce却进行全局计算,完美地符合了他对数据处理的期望!
    Hadoop也存在某个节点数据丢失的问题,但随着流式计算,丢失的数据终究会随着系统的正常而被最终合并,因此数据最终是一致的。
    Hadoop不能进行实时计算咋办?作者又构建了一套基于Cassandra和ElephantDB的实时数据处理系统。。。。搞的无比复杂!

    3.4 质疑4:分区容错概念有误导

    【5】的作者主要质疑【6】,但比较清晰得揭露了CAP的概念之间的模糊。
    【5】认为,可用性和一致性是分布式系统的属性,而分区却是网络的一个属性。不能再问题发生时是否选择要不要分区,而是应该在分区既定的情况下选择要一致性还是可用性。网络分区会发生在两种情况:
    • 交换机失败,导致网络发生【6】中描述的情况,网络被分成几个子网
    • 机器延迟或死机,导致某些server失去联系
    【6】中所谓的分区就是情况1,每个独立的子网还能正常运作,作者认为这种分区条件非常苛刻,更倾向于认为这只是分区可用性的一种度量方式(发给每个子网的请求都有正确的response)。
    而实际上,因为机器原因发生的分区的情况更常见一些,如果“很多”机器都发生故障,系统会因为一个“多数派”的丢失而导致不可用(比如,因为多数不存在,最新的读可能无法读取到上一次的写)。一句话:分区也同时蕴涵着不可用,这两个概念之间存在重叠。
    作者认为,CAP比较合理的表达方式应该是:在一个允许网络发生故障的系统中,该选择一致性还是可用性?
    当系统的机器数量持续增加时,一致性会加剧时延,维护一致性的成本会非常之高,因此我们基本就剩下一种选择:在允许网络失败的系统中,更多地是选择可用性。而Zookeeper、Hadoop之所以选择一致性,是因为这些系统多数是有在同一集群的少数节点构成!
    【5】的作者其实间接地否认了“3个中同时满足2个”这样的误解,而是从更深层次探讨了CAP的本质,但并没有试图推翻CAP。

    4.对质疑的回应

    面对大量的质疑,Brewer和Lynch终于坐不住了,因此两人纷纷出来澄清:
    Brewer于2012年重申【1】:
    • ”3个中的2个“这个表述是不准确的,在某些分区极少发生的情况下,三者能顺畅地在一起配合
    • CAP不仅仅是发生在整个系统中,可能是发生在某个子系统或系统的某个阶段
    该声明并不否认像质疑3那种三个因素协同工作的情况,并把CAP应用在一些更细粒度的场景中。

    Lynch也在10年后的2012年重写了论文【3】,该论文主要做了几件事:
    • 把CAP理论的证明局限在原子读写的场景,并申明不支持数据库事务之类的场景
    • 一致性场景不会引入用户agent,只是发生在后台集群之内
    • 把分区容错归结为一个对网络环境的陈述,而非之前一个独立条件。这实际上就是更加明确了概念
    • 引入了活性(liveness)和安全属性(safety),在一个更抽象的概念下研究分布式系统,并认为CAP是活性与安全熟悉之间权衡的一个特例。其中的一致性属于liveness,可用性属于safety
    • 把CAP的研究推到一个更广阔的空间:网络存在同步、部分同步;一致性性的结果也从仅存在一个到存在N个(部分一致);引入了通信周期round,并引用了其他论文,给出了为了保证N个一致性结果,至少需要通信的round数。也介绍了其他人的一些成果,这些成果分别都对CAP的某一个方面做出了特殊的贡献!
    其实Lynch的论文主要就是两件事:缩小CAP适用的定义,消除质疑的场景;展示了CAP在非单一一致性结果下的广阔的研究结果!并顺便暗示CAP定理依旧正确!
    从此论文还是可以看出,Lynch的功力高出其他质疑者好多!

    5. 该如何看待CAP?

    首先肯定的是,CAP并不适合再作为一个适应任何场景的定理,它的正确性更加适合基于原子读写的NoSQL场景。质疑虽然很多,但很多质疑者只是偷欢概念,并没有解决各个因素之间的取舍问题。而无论如何C、A、P这个三个概念始终存在任何分布式系统,只是不同的模型会对其有不同的呈现,可能某些场景对三者之间的关系敏感,而另一些不敏感。在所有的质疑当中,质疑4是分析的比较中肯的,其清晰的概念分析该让我们对CAP有更深入的理解!
    就像Lynch所说,现在分布式系统有很多特性,比如扩展性、优雅降级等,虽然时间的发展,或许这些也会被纳入研究范畴,而作为开发者,这都是我们需要考虑的问题,而不仅是CAP三者!

    6.参考资料 

    【1】http://en.wikipedia.org/wiki/Cap_theorem
    【2】http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf
    【3】http://groups.csail.mit.edu/tds/papers/Gilbert/Brewer2.pdf
    【4】http://markburgess.org/blog_cap.html
    【5】http://blog.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/
    【6】http://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database-systems-eventual-consistency-and-the-cap-theorem/fulltext
    【7】http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
    【8】http://highscalability.com/blog/2011/11/23/paper-dont-settle-for-eventual-scalable-causal-consistency-f.html
    展开全文
  • 什么是分布式系统的CAP理论? 2000年7月,加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后,麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后,CAP理论正式成为分布式计算...
  • CAP理论的理解

    2020-04-16 14:36:34
    CAP定理的由来 CAP定理是加州伯克利分校计算机科学家埃里·布鲁尔(Eric Brewer)于1998年提出的一个假说,并在2000年的分布式计算原则研讨会上发表。在2002年,麻省理工学院的赛斯·吉尔伯特(Seth Gilbert)和南希·...
  • CAP理论和BASE理论

    千次阅读 2018-09-12 22:09:17
    CAP理论 在设计和部署分布式系统时,存在三个明显的需求: C(Consistency)一致性。即分布式数据应该同步,保存一致。 A(Availability)可用性。指系统能够很好的为用户提供服务,主要体现在用户访问之后能很 快的...
  • [分布式]:分布式系统的CAP理论

    千次阅读 2018-07-16 16:20:38
    2000年7月,加州大学伯克利分校的Eric ...之后,CAP理论正式成为分布式计算领域的公认定理。 CAP理论概述 一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition...
  • CAP理论,浅谈我的理解

    千次阅读 2019-02-09 17:32:41
    想必大多数的IT从业者,都听过CAP理论,但是听过和理解并熟练应用又是两码事,笔者也看了几篇文章,就想在这片里浅谈一下我的理解。 CAP理论,是指在一个互相连接且共享数据的分布式系统中,当涉及读写操作时,只能...
  • Redis中的CAP理论

    万次阅读 2020-08-21 08:34:02
    Redis中的CAP理论CAP理论C:consistency(一致性)A:avalibility(可用性)P:Partition(分区)-tolerence to partition(分区容忍度)图解CAPP【分区】A【可用性】C【一致性】解释CAP分区:一个分布式系统,网络不通讯,导致...
  • CAP原理这样理解最简单

    千次阅读 多人点赞 2018-07-10 13:49:04
    众所周知,CAP理论是架构师在设计分布式系统过程中,处理数据一致性问题时必须考虑的基石级理论(圣经级的,^V^)。大意是说,在分布式网络分区环境中,数据的一致性、可用性和分区容忍性三者之间,至多只能保证两者...
  • 什么是CAP理论? 2000年7月,加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后麻省理工学院的Seth Gilbert和NancyLynch从理论上证明了CAP,之后CAP理论正式成为分布式计算领域的公认定理。 ...
  • 大家在看书或者参加会议的时候,对于数据架构设计的时候,一定经常听到CAP原理,比如根据CAP原理,对于分布式设计系统,只能做到数据的最终一致性而不是实时事务的一致性;那么,这些行家或者架构师常挂在嘴边的CAP...
  • ZooKeeper和CAP理论及一致性原则

    千次阅读 2020-03-19 16:44:38
    ZooKeeper和CAP理论及一致性原则 一、CAP理论概述 CAP理论告诉我们,一个分布式系统不可能同时满足以下三种 一致性(C:Consistency) 可用性(A:Available) 分区容错性(P:Partition Tolerance) 这三个...
  • 分布式系统架构常识:CAP理论

    千次阅读 2018-01-06 16:55:08
    什么是CAP理论? 2000年7月,加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后麻省理工学院的Seth Gilbert和NancyLynch从理论上证明了CAP,之后CAP理论正式成为分布式计算领域的公认定理。 ...
  • 分布式系统的 CAP 定理

    千次阅读 2018-08-07 17:30:45
    CAP定理指出,在一个分布式系统中,对于一致性、可用性、分区容错这三个特性,不可能同时满足,而是必须有所舍弃。我们设计分布式系统时,必须在三者之间(尤其是一致性和可用性之间)有所取舍和平衡。 作者:王...
  • CAP理论与HBase

    千次阅读 2015-06-23 18:14:43
    The short summary of the article is that CAP isn’t “C, A, or P, choose two,” but rather “When P happens, choose A or C.”Partitions, like death and taxes, are unavoidable – think of machine ...
  • CAP和BASE理论理解

    千次阅读 2017-08-24 17:56:28
    分布式系统都是基于CAP/BASE理论进行设计的。CAP/BASE在分布式系统设计过程中提供了最基本的也是最重要的原则。 正确的理解CAP/BASE能够更好的指导分布式系统的设计,当然了只有经历了大量的分布式系统实战,才能...
  • Eureka&CAP原理

    千次阅读 2017-12-25 19:08:40
    CAP原则(CAP定理): CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。 CAP原则是NOSQL数据库的基石。...
  • Consul CAP理论纠错

    千次阅读 2018-12-26 12:22:24
    Consul CAP理论纠错 随便搜索Consul、zookeeper、etcd、eureka注册中心比较相关博客文章,你都会发现千篇一律的是以下这幅对比图:但是我对Consul使用的是CA架构还是CP架构产生了疑问,于是我查看的Consul官网相关...
1 2 3 4 5 ... 20
收藏数 22,439
精华内容 8,975
关键字:

cap理论