初识CAP

初识CAP

分布式是一个古老而又流行的概念了,当今只要是规模稍微大一点的项目,单机承担不了的,那么就一定会涉及到分布式的知识,其实可以想一下,不管现在的大数据、云计算、AI多么火热,但是底下的主机依旧是这么大的,如今摩尔定律似乎已经接近饱和,那么当单机承担不了压力的时候怎么办?构建分布式集群啊,在为我们提供了一个解决办法的同时,也增加了系统的复杂性,因为很多单机时代的东西,到了分布式情况下就不适用了,这似乎不是一个维度上面的事情,比如一致性,单机时代,世界那么美好,一切那么单纯,数据库的ACID特性是那么完美无瑕,但是在分布式系统中,你可以保证强一致性,但是会牺牲掉一些东西,例如可用性,这就引出了这篇文章要学习的内容,CAP

参考文章:http://www.hollischuang.com/archives/666

CAP

Consistency 一致性

在介绍Consistency之前,先了解一些几种一致性策略:

  • 强一致性:要求更新的数据能被后面的访问都看到
  • 弱一致性:数据更新后,能够容忍后面的一部分访问看不到,甚至可以容忍全部访问看不到
  • 最终一致性:经过一段时间之后可以访问的到

一致性问题往往会在并发情况下产生,例如:

img

初始条件下两台主机中的数据均为v0,这时客户端向G1中写入v1

img

但是这时另外一个客户端读取系统中的数据时,请求刚好分配到了G2主机,这时读到的数据却是v0,这时也就产生了一致性问题,如何保证更新过后的数据同步到整个系统,这也是分布式主要关心的内容

数据同步:

img

Availability :可用性

也就是字面意思,在一个满足可用性的分布式系统中,要求每一个非故障的节点必须对一个请求做出响应,一般根据停机时间的比率来衡量,这和用户体验直接相关,目前的系统设计将高可用性作为一个非常重要的标准

Partition Tolerance分区容错性

当分布式系统中的主机或者网络出现问题时,要保证依然可以对外提供正常的、满足一致性和可用性的服务,一个分区容错性比较好的系统看上去就是一个整体

CAP权衡

从这个理论被提出来的第一天起,就已经像世人整明,一个系统 无法同时满足一致性、可用性、分区容错性,接下来看一下具体的情况,如何在之中做出权衡:

CA without P

这种情况几乎是不存在的,分布式系统成立的前提一定是要满足分区容错性,既然你使用了分布式,那么使用网络将各个主机连接起来构建一个完成的分布式系统,那就是必须的,但是当一个主机或者网络出现故障,这个系统就不可用的话,那么真的没有讨论下去的必要了,系统都停机了,你还玩个屁的一致性和可用性啊,,

所以接下来的情况讨论中,P一定是成立的

CP without A

这种情况就是要舍弃掉一定的可用性,反应在产品上就是请求丢失,请求超时,比较影响用户体验,但是在一些数据很重要、对数据很敏感的系统中,看样子也只能这样做,例如电商系统中, 你发送给一个主机的请求是下单,而你查询物流的信息发送到了另一个主机上,可是他们之间并没有进行同步,你看不到自己的包裹信息,以为是下完单丢了,这对于一个电商系统来说是无法容忍的

AP wihtout C

看到原文博主说这种搭配是很多的,也是感到惊讶,看来系统对于可用性真的是看的很重,用户是上帝啊,印象分很重要, 阿里每年都自称可用性做到了5个9,看来还是会牺牲掉一些一致性作为妥协的,但是这里的一致性往往指的是强一致性,还是会保障最终一致性的,我能想到的例子就是平时抢红包的时候,抢红包就是一个非常典型的高并发事件,不知道大家有没有遇到多,我有时候虽然能打开红包页面,已经露出了小铜钱,但是当我准备收钱的时候却提示我:来晚了,已经被抢光了, 我想这就是牺牲掉一些一致性来保证可用性的例子,用户虽然能打开红包,满足了可用性,但是当数据完全最终一致性的时候,这就会抢不到。


​ 这也算是第一次接触这个理论,我觉得自己的文章题目起的很好,初识CAP,今天看到的理论还只是冰山一角,这是很复杂的领域,既然大前提就是不能同时满足,我想最终在系统设计时候,还是要根据具体的业务需求来选择吧,没有最好的,只有最合适的。