ICE.ICE|

韩憨

园龄:4年7个月粉丝:42关注:47

CAP原理详解

转载 https://blog.csdn.net/u013332124/article/details/82874178

 

一、CAP原理介绍

先简单介绍一下CAP原理是什么:

C:Consistency

即一致性,访问所有的节点得到的数据应该是一样的。注意,这里的一致性指的是强一致性,也就是数据更新完,访问任何节点看到的数据完全一致,要和弱一致性,最终一致性区分开来。

A:Availability

即可用性,所有的节点都保持高可用性。注意,这里的高可用还包括不能出现延迟,比如如果节点B由于等待数据同步而阻塞请求,那么节点B就不满足高可用性。

也就是说,任何没有发生故障的服务必须在有限的时间内返回合理的结果集。

P:Partiton tolerance

即分区容忍性,这里的分区是指网络意义上的分区。由于网络是不可靠的,所有节点之间很可能出现无法通讯的情况,在节点不能通信时,要保证系统可以继续正常服务。

以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择

CAP原理说,一个数据分布式系统不可能同时满足C和A和P这3个条件。所以系统架构师在设计系统时,不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。由于网络的不可靠性质,大多数开源的分布式系统都会实现P,也就是分区容忍性,之后在C和A中做抉择。

对CAP原理的一些常见的理解误区

看到网上很多文章说CAP原理是分布式系统的基石,但是CAP原理其实是对分布式数据存储系统的一个定论。我们假设一个分布式系统各个节点都读写同一个mysql实例,那么对于这个分布式系统来说,讨论CAP原理是没有意义的。因为各个节点之间可以不用因为数据复制而进行通信,满足分区容忍性(P),可以随时响应请求,满足可用性(A),同时因为访问的是一个数据库实例,本身已经保证了数据一致性(C)。

因此,在讨论CAP原理的时候,更多的是针对那些有数据存储、数据复制场景的分布式存储系统,也就是我们熟悉的NoSql数据库。

由于我们大多数人都不会去设计一款新的NoSql数据库来使用,更多的是使用现成的NoSql开源系统进行数据的存储,比如Hbase、MongoDB、Cassandra等。所以大多数时候,其实我们都用不上CAP原理。

虽然用不上,但是了解一下还是没有坏处的。下面简单证明一下CAP

二、CAP原理简单证明

假设有节点data1和节点data2,一开始有个数据number=1。之后向data1提交更新,将数据number设置为2。

接着data1就需要将更新推送给data2,让data2也更新number数据。

接下来我们分3个场景分析:

1. 在保证C和P的情况下

为了保证数据一致性,data1需要将数据复制给data2,即data1和data2需要进行通信。但是由于网络是不可靠的,我们系统有保证了分区容忍性,也就是说这个系统是可以容忍网络的不可靠的。这时候data2就不一定能及时的收到data1的数据复制消息,当有请求向data2访问number数据时,为了保证数据的一致性,data2只能阻塞等待数据真正同步完成后再返回,这时候就没办法保证高可用性了。

所以,在保证C和P的情况下,是无法同时保证A的。

2. 在保证A和P的情况下

为了保证高可用性,data1和data2都有在有限时间内返回。同样由于网络的不可靠,在有限时间内,data2有可能还没收到data1发来的数据更新消息,这时候返回给客户端的可能是旧的数据,和访问data1的数据是不一致的,也就是违法了C。

也就是说,在保证A和P的情况下,是无法同时保证C的。

3. 在保证A和C的情况下

如果要保证高可用和一致性,只有在网络情况良好且可靠的情况下才能实现。这样data1才能立即将更新消息发送给data2。但是我们都知道网络是不可靠的,是会存在丢包的情况的。所以要满足即时可靠更新,只有将data1和data2放到一个区内才可以,也就丧失了P这个保证。其实这时候整个系统也不能算是一个分布式系统了。

理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致,即丧失了C性质。如果为了保证数据一致性,将分区一侧的节点设置为不可用,那么又丧失了A性质。除非两个节点可以互相通信,才能既保证C又保证A,这又会导致丧失P性质。

三、CAP原理在各个系统的应用

在这里插入图片描述

四、总结

关于CAP原理,还需要特别注意的一点是,虽然说我们设计系统时不能同时保证拥有三点。但是也并不是说,保证了其中2点后,就要完全抛弃另外一点。只是相对的要做一些牺牲。比如在保证CP的情况下,虽然没办法保证高可用性,但这不意味着可用性为0,我们可以通过合理的设计尽量的提高可用性,让可用性尽可能的接近100%。同理,在AP的情况下,也可以尽量的保证数据的一致性,或者实现弱一致性,即最终一致性。

作者认为,对于大数据的研发人员,CAP原理还是有必要理解的。理解了CAP原理后,再去看一些开源的NoSql实现原理也会比较好理解一些。

本文作者:韩憨

本文链接:https://www.cnblogs.com/hanby/p/14183711.html

版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。

posted @   韩憨  阅读(960)  评论(0编辑  收藏  举报
//看板娘

剑桥

评论
收藏
关注
推荐
深色
回顶
收起
  1. 1 隔离 (Studio Live Duet) 陈凯咏,林家谦
  2. 2 明知做戏 吴雨霏
  3. 3 残酷游戏 卫兰
  4. 4 你,好不好? 周兴哲
  5. 5 我可以 蔡旻佑
  6. 6 云烟成雨 房东的猫
  7. 7 说散就散 JC 陈咏桐
  8. 8 我配不上你 夏天Alex
  9. 9 不再联系 夏天Alex
  10. 10 等我先说 夏天Alex
  11. 11 我知道他爱你 夏天Alex
  12. 12 多想在平庸的生活拥抱你 隔壁老樊
  13. 13 这一生关于你的风景 隔壁老樊
  14. 14 我曾 隔壁老樊
  15. 15 关于孤独我想说的话 隔壁老樊
  16. 16 过客 周思涵
  17. 17 备爱 周思涵
  18. 18 嚣张 en
  19. 19 海口 后弦
明知做戏 - 吴雨霏
00:00 / 00:00
An audio error has occurred, player will skip forward in 2 seconds.

作词 : Xia Zhi

作曲 : Fong Man Leung

编曲 : 吴国恩

监制 : Gary Chan

等你的汽水喝一半给你加片薄冰

等你的桌面满泻我总会打理重整

不想纯情 不够聪明

你未发现我的身影

得我帮你依照编码整理家里电影

得我帮你依照编码整理家里电影

只会得我一个帮你选购喜爱铃声

天天如常 估你心情

等一个眼神求证 一闪擦过如流星

怎么我为我做过的感到惊怕

就像爱吗我也不肯定恐怕

我以为存在吗 千变万化

从来不肯开口可相信吗 离谱吗

请你不要阻我喜欢你

明明是爱但你未说话你扮作闪避

这个沉默冷静的你毫无办法处理

其实我亦怕是错摸心理

总有天会等到好天气

游行示爱大叫着你在某大片草地

等你无用退避不过仍然害羞的你

还是顾忌太不争气 明知做戏

即使你未太在意不感到惊讶

即使你未太在意不感到惊讶

现在要说爱你请准备招架

勇气还存在吗 不要害怕

随时真的胆敢亲手送花 离谱吗

请你不要阻我喜欢你

明明是爱但你未说话你扮作闪避

这个沉默冷静的你亳无办法处理

其实我亦怕是错摸心理

总有天会等到好天气

游行示爱大叫着你在某大片草地

等你无用退避不过仍然害羞的你

还是顾忌太不争气 明知做戏

不过不要阻我紧张你

如何令你愉快让我办妥为你准备

喜爱沉默冷静的你还是自信的你

仍愿意为你造一些惊喜

总有天会等到好天气

游行示爱大叫着你在某大片草地

等你无用退避不过途人目光不理

期待贴着你的手臂 无须做戏

等你喜爱等你不爱就凭摘毫验证

等你喜爱等你不爱就凭摘毫验证

想爱不爱偏爱不理亦同样难划清

天天如常 估你心情

不想扑索来求证 争取过趁还年青

终于你下决定来答应 太动听

点击右上角即可分享
微信分享提示