CAP理论被很多人拿来作为分布式系统设计的金律,然而感觉大家对CAP这三个属性的认识却存在不少误区,那么什么是CAP理论呢?CAP原本是一个猜想,2000年PODC大会的时候大牛Brewer提出的,他认为在设计一个大规模可扩放的网络服务时候会遇到三个特性:一致性(consistency)、可用性(Availability)、分区容错(partition-tolerance)都需要的情景,然而这是不可能都实现的。之后在2003年的时候,Mit的Gilbert和Lynch就正式的证明了这三个特征确实是不可以兼得的。

CAP是Consistency、Availablity和Partition-tolerance的缩写。分别是指:
1)一致性(Consistency):每次读操作都能保证返回的是最新数据。也就是说所有的节点数据一致!
2)可用性(Availablity):任何一个没有发生故障的节点,会在合理的时间内返回一个正常的结果。也就是说一个或者多个节点失效,不影响服务请求!
3)分区容忍性(Partition-torlerance):当节点间出现网络分区,照样可以提供服务。也就是说节点间的网络连接失效,仍然可以处理请求!

其实,任何一个分布式系统,需要满足这三个中的两个。CAP理论指出:CAP三者只能取其二,不可兼得。其实这一点很好理解,理由如下:
1-  首先,单机都只能保证CP。
2-  有两个或以上节点时,当网络分区发生时,集群中两个节点不能相互通信(也就是说不能保证可用性A)。此时如果保证数据的一致性C,那么必然会有一个节点被标记为不可用的状态,违反了可用性A的要求,只能保证CP。
3- 反正,如果保证可用性A,即两个节点可以继续各自处理请求,那么由于网络不通不能同步数据,必然又会导致数据的不一致,只能保证AP。

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

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

二、多副本

相比于单实例,这里多了一个节点去备份数据。
对于读操作来说,因为可以访问两个节点中的任意一个,所以可用性提升。

对于写操作来说,根据更新策略分为三种情况:
1)同步更新:即写操作需要等待两个节点都更新成功才返回。这样的话如果一旦发生网络分区故障,写操作便不可用,牺牲了A。
2)异步更新:即写操作直接返回,不需要等待节点更新成功,节点异步地去更新数据(FastDFS文件系统的存储节点就是用这种方式,写完一份数据之后立即返回结果,副本数据由同步线程写入其他同group的节点)。这种方式,牺牲了C来保证A,即无法保证数据是否更新成功,还有可能会由于网络故障等原因,导致数据不一致。
3)折衷:更新部分节点成功后便返回。

三、分片

相比于单实例,这里多了一个节点去分割数据。
由于所有数据只有一份,一致性得以保证;节点间不需要通信,分区容忍性也有。
然而,当任意一个节点挂掉,丢失了一部分的数据,系统可用性得不到保证。

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

那么,有哪些好处呢?
1)某个节点挂掉只会影响部分服务,即服务降级;
2)由于分片了数据,可以均衡负载;
3)数据量增大/减小后可以相应的扩容/缩容。

大多数的数据库服务都提供了分片的功能。如Redis的slots,Cassandra的patitions,MongoDB的shards等。
基于分片解决了数据量大的问题,可是我们还是希望我们的系统是高可用的,那么,如何牺牲一定的一致性去保证可用性呢?

四、集群

可以看到,上面这种方式综合了前两种方式。同上分析,采用不同的数据同步策略,系统CAP保证各有不同。不过,一般数据库系统都会提供可选的配置,我们根据不同的场景选择不同的特性。
其实,对于大多数的非金融类互联网公司,要求并非强一致性,而是可用性和最终一致性的保证。这也是NoSQL流行于互联网应用的一大原因,相比于强一致性系统的ACID原则,它更加倾向于BASE:
-  Basically Available:基本可用性,即允许分区失败,除了问题仅服务降级;
-  Soft-state:软状态,即允许异步;
-  Eventual Consistency:最终一致性,允许数据最终一致性,而不是时刻一直。

五、总结
基本上,上面讨论的几种方式已经涵盖了大多数的分布式存储系统了。
其实对于大规模分布式系统来说,CAP是非常稳固的,可以扩展的地方也不多。
它很大程度上限制了大规模计算的能力,通过一些设计方式来绕过CAP管辖的区域或许是下一步大规模系统设计的关键。
可以看到,这些个方案总是需要通过牺牲一部分去换取另一部分,总没法达到100%的CAP。选择哪种方案,依据就是在特定场景下,究竟哪些特性是更加重要的了。

Linux下分布式系统以及CAP理论分析的更多相关文章

  1. 分布式系统之CAP理论杂记[转]

    分布式系统之CAP理论杂记 http://www.cnblogs.com/highriver/archive/2011/09/15/2176833.html 分布式系统的CAP理论: 理论首先把分布式 ...

  2. 分布式系统之CAP理论杂记

    分布式系统的CAP理论:理论首先把分布式系统中的三个特性进行了如下归纳:● 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值.● 可用性(A):在集群中一部分节点故障后,集群整体是否 ...

  3. 分布式系统的CAP理论

    一.CAP理论概述 一个分布式系统最多只能同时满足一致性(Consistency).可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项. 二.CAP ...

  4. Linux下的IO监控与分析

    Linux下的IO监控与分析 近期要在公司内部做个Linux IO方面的培训, 整理下手头的资料给大家分享下 各种IO监视工具在Linux IO 体系结构中的位置 源自 Linux Performan ...

  5. 分布式系统之CAP理论

    任老师第一节主要讲了分布式系统实现时候面临的八个问题,布置的作业就是这个,查询CAP理论. 笔者初次接触分布式,所以本文主要是一个汇总. 一.CAP起源 CAP原本是一个猜想,2000年PODC大会的 ...

  6. 分布式系统:CAP 理论的前世今生

    CAP 理论是分布式系统设计中的一个重要理论,虽然它为系统设计提供了非常有用的依据,但是也带来了很多误解.本文将从 CAP 诞生的背景说起,然后对理论进行解释,最后对 CAP 在当前背景下的一些新理解 ...

  7. 看完这篇,保证让你真正明白:分布式系统的CAP理论、CAP如何三选二

    引言 CAP 理论,相信很多人都听过,它是指: 一个分布式系统最多只能同时满足一致性(Consistency).可用性(Availability)和分区容错性(Partition tolerance) ...

  8. 转载:分布式系统的CAP理论

    原文转载Hollis原创文章:http://www.hollischuang.com/archives/666 2000年7月,加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提 ...

  9. 重温分布式系统的CAP理论

    1. CAP理论的历史 2000年7月,Eric Brewer教授提出CAP猜想:2年后,Seth Gilbert和Nancy Lynch从理论上证明了CAP:之后,CAP理论正式成为分布式计算领域的 ...

随机推荐

  1. oracle中给某个用户某张表的权限设置

    今天碰到需要给数据库上某一个用户,开通其中2张表的查询权限,方法如下: grant select on bas_checkcycle to jdc;这个是整个语句. 语句分析: grant selec ...

  2. late_initcall和module_init的区别

    在init.h中有如下定义: 详情参照:linux 设备驱动加载的先后顺序 #define pure_initcall(fn) __define_initcall("0",fn,1 ...

  3. Centos7.5.1804永久生效修改主机名

    原来主机名 [root@node1 ~]# 查看Centos的版本: [root@node1 ~]# cat /etc/redhat-release CentOS Linux release (Cor ...

  4. 【夯实PHP基础】微信小程序开发 2017.02.06

    本文地址 分享提纲 1. 概述 2. 简易教程 1. 概述 1)[小程序是什么] 微信小程序是一种全新的连接用户与服务的方式,它可以在微信内被便捷地获取和传播,同时具有出色的使用体验. 2)[快速体验 ...

  5. ZooKeeper学习总结 第二篇:ZooKeeper深入探讨

    其实zookeeper系列的学习总结很早就写完了,这段时间在准备找工作的事情,就一直没有更新了.下边给大家送上,文中如有不恰当的地方,欢迎给予指证,不胜感谢!. 1. 数据模型 1.1. 只适合存储小 ...

  6. 多个Activity和Intent

    Intent是Android应用程序组件之一,在Android系统当中表示一种意图,Intent中包含了一组信息: 最重要的内容是action(动作)和data(数据) Component name ...

  7. swift 该死的派发机制--待完成

    swift 该死的派发机制 final static oc类型 多态类型 静态类型 动态函数  静态函数 nsobject: 1.缺省不再使用oc的动态派发机制: 2.可以使用nsobject暴露出来 ...

  8. 数据挖掘十大算法--K-均值聚类算法

    一.相异度计算  在正式讨论聚类前,我们要先弄清楚一个问题:怎样定量计算两个可比較元素间的相异度.用通俗的话说.相异度就是两个东西区别有多大.比如人类与章鱼的相异度明显大于人类与黑猩猩的相异度,这是能 ...

  9. mysql中左连接后,最终的记录数大于左边表的记录分析

    如果B表符合条件的记录数大于1条,就会出现1:n的情况,这样left join后的结果,记录数会多于A表的记录数. 例如:member与member_login_log表的结构如下,member记录会 ...

  10. [HAOI2017]供给侧改革

    题目 这道题我们其实就是利用了一棵后缀树 由于字符串是随机的,所以这个后缀树的树高是\(log\)的,基于树高的算法是能过的 我们考虑后缀树上的两个节点的\(lca\)就是这两个节点所代表的后缀的\( ...