分布式系统中的 CAP 理论

CAP 概念

C(Consistency):一致性

在分布式系统中,所有的计算机节点的数据在同一时刻都是相同的,数据都是一致的。不能因为分布式导致不同系统拿到的数据不一致。也就是说,用户在某一个节点写了数据,在其他节点获得该数据的值是最新的;如若是更新操作,那么所有用户看到的也是更新后的新的值,不论哪个节点,不论集群,不论主备,获得的数据都是相同的。

A(Availability):可用性

保证你的系统可用,也就是说无论任何时候,系统都可以被用户访问到,用户可以获得正常的响应结果。比如做好集群啊,做好主备啊等等,这个就是高可用。

P(Partition tolerance):分区容错性

在整个分布式系统中,我们都是部署在不同的节点上,或者是不同的机房甚至是不同的地域,部署的时候会有一些子网,某一些服务会部署在不同的子网,每个子网就是一个区,也就是网络分区,分区和分区之间的通信也有可能出现通信故障。某个节点或者网络或者地域(分区)出现问题,整体整个系统还是照样能够提供一致性和可用性的服务。也就是说部分系统故障不会影响整体。为什么会这样,主要是因为有程序bug,计算机硬件问题,网络问题,网线被挖断了等等造成的综合因素。所以呢,我们的诉求就是即使小部分出问题,也要保全整体。并且对于任何分布式系统来讲,都需要去考虑分区容错的问题。

CAP 无法同时满足

在分布式系统中,一般很难同时满足C和A(一致性和可用性),想达到高可用,那么系统集群肯定很庞大,不同地域间都有互备之类的,各个节点之间的通信就会有延迟,这样数据的一致性就无法保证了。同理想达到高一致性,那么各个节点之间的通信就需要等待或阻塞,让数据同步,阻塞的时候这个系统就不可高用了。
分布式系统中的 CAP 理论

组合搭配

那么 CP,AP,CA,这三种,哪个好呢?

  • CP:满足一致性和分区容错的系统,性能不会很高,因为一致性是时时保持的。就比如说我提交一个订单,这个订单的数据要同步到各个系统,保证强一致性。那么这样用户请求大多都会被阻塞。需要耗时等待。redis,mongodb,hbase都是CP。(redis集群如果一个主节点挂了,那么slave成为master,他会有一个时间段导致不可用,A不满足)
  • CA:满足一致性,满足可用性,一般来说都是以单体存在的集群架构,可扩展性不高。一般都是关系型数据库。
  • AP:满足可用性和分区容错,那么这样就不是一致性了,往往会采用弱一致性,或者最终一致性。这也是通常用的最多的。 我们平时开发的系统就是以AP来展开工作的。

对于我们平时开发的时候,分区容错P是一定要满足的,因为我们在部署的时候往往都都是多节点集群部署,设置异地互备,比如北京机房和机房都提供服务 ,所以,一定要容错。

那么接下来我们要抉择 一致性 还是 可用性 呢?
一般来说,往往我们在大家网站架构的时候,我们都会采用AP,主流的互联网公司也是如此,也就是数据的弱一致性,因为要保证系统的整体的高可用性以及容错性。啥叫弱一致性,比如我们经常看头条,头条的点赞数评论数或者微博粉丝数,具体的数值每个人浏览的时候可能不一样,这个其实无所谓的,这就是弱一致性。而像Redis啊MongoDB这样的中间件,是CP,也就是要保证数据的一致性,因为毕竟要为网站提供数据服务的,一致性必须满足。

关于弱一致性

其实现在的互联网环境里,很多项目都不会采用强一致性,因为很难做,而往往采用弱一致性,因为用户可以接受。比如双11或者618的时候,订单蹭蹭蹭的海量增加,我们只需要关注订单下单成功就行,具体多少订单,具体多少金额,我们不会去实时的统计计算的,因为没必要,会在高峰期过后逐步去统计,慢慢的实现一致性。那么这个就是目前主流的做法。

但是一定要注意,数据层面的交互,关系型数据库,redis,mongodb等,他们肯定是强一致性,因为需要提供给你的网站数据服务。

其实呢,我们在互联网环境里,往往会采用BASE理论,
Base = Basically Available Soft-state Eventually-Consistent
也就是达到基本可用软状态的最终一致性。它是比较平衡了CAP后得到的结论,这也是绝大多数互联网系统实践后的一个结果,他主要的核心思想就是忽略强一致性,使用弱一致性来达到最终一致。

分布式系统中的 CAP 理论

上一篇:2021做软件测试的第三方软件检测机构排名


下一篇:编程-并查集