阅读 196

人人都想学架构(四):CAP理论

原文链接: mp.weixin.qq.com

本文是《从0开始学架构》专栏学习的第四篇,主要讲解高可用架构,本文记录的是第六节CAP,CAP是一个理论,有很多不同的版本,所以理解的时候非常困惑,我觉得作者这个版本讲解的很全面,结合留言,让我对它的理解更上一层楼了,理论毕竟是理论,也没有绝对的对与错,重要的是学会思路,以便解决问题。

什么是CAP,在一个分布式系统(指互相连接并共享数据的节点的集合)中,当涉及读写操作时,只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个,另外一个必须被牺牲。

分布式系统一定是有多个节点的,节点是互联的,共享代表某个节点有其他节点的数据(每个节点的数据不一定有全部数据)。按照这个理解,Memcached集群中每个节点数据都是独立的,所以不是CAP探讨的对象。

MySQL主从集群看上去算CAP探讨的对象,从写数据的角度看也能符合CA系统,可它是一个单点系统,如果遇到主库故障,则整个写服务就不可用了,如果是单点系统,这就不算一个分布式系统了(以上的领悟来源于留言,也是今天的收获)。

什么是一致性,首先要从客户端的角度去看,读操作保证能返回最新的写操作结果,其实一致性是CAP中最让人困惑的一个概念,专栏没有细说,最近在看《NoSQL精粹》这篇文章,讲的更全面。

CAP中的一致性表示线性一致性。最新的结果不代表节点之间数据是相同的,比如在更新一个事务的时候,某个节点拥有了最新的数据,但还没有提交,从这个角度看,其他节点没有办法获取未提交事务的数据。

什么是可用性,非故障的节点在合理的时间内返回合理的响应(reasonable response)。

客户端和节点之间如果有故障,这个和此处的非故障节点不是一回事,在分布式系统中,集群中的某个节点肯定会遇到故障,这个故障会影响其他非故障节点。

合理的响应表示没有错误或超时(如果不能连接其他节点或者连接超时则表示不具备可用性),但成功响应结果不代表是正确的(逻辑上)。

CAP中的可用性和高可用不一样,高可用是指部分实例挂了,能自动摘除,并由其它实例继续提供服务,关键是冗余。

什么是分区容忍性,当出现网络分区后,系统还能够“履行职责”,网络分区表示集群中某些节点不能和其他节点互通了,可能是丢包,也可能是连接中断,或者网络拥塞。履行职责和可用性是一致的,就是 reasonable response。

在分布式系统中,CAP中的P一定会发生,如果我们选择了 CA 而放弃了 P,那么当发生分区现象时,为了保证 C,系统需要禁止写入,当有写入请求时,系统返回 error(例如,当前系统不允许写入),这又和 A 冲突了,因此分布式系统理论上不可能选择 CA 架构,只能选择 CP 或者 AP 架构。关于这一点,放弃P其实代表单点故障,MySQL主从是符合的,可分布式系统写入点不仅仅是一个节点,因为它们都是分片或分区的,那这个怎么牺牲?有个用户也留言了说牺牲P,说好说,怎么牺牲?理论和实践上还是有很长的路

什么是CP,见下图:

由于分区造成同步问题,为了保证P和C,系统必须告诉用户功能部分不可用,由于是不可用,间接说明客户不会遇到最新数据的问题了。

保证P,代表系统在分区的情况下还能提供部分功能。

什么是AP,见下图:

发生分区后,为了保证A,此时客户拿不到最新的数据,牺牲了C。

以上内容好像很好理解,但作者认为这些概念太抽象化了,省去了很多细节,在具体实践的时候,由于情况很复杂,很容易出现误解和偏差,所以下面说的才是重点。

1:CAP关注大力度是数据,而不是整个系统。

根据数据的不同应用场景,选择性的使用CP或者AP,不是说一个系统只能选择CP或AP。

2:CAP是忽略网络延迟的

可这个问题确实又存在,在分布式环境下无法做到完美,所以对于一些重要级别的操作(比如用户余额),在这种情况下,只能选择CA,也就是单点写入,其他节点做备份,无法做到分布式下的多点写入。(非常感谢,我读了很多遍才有了体会)。

关于这点感觉说的就是MySQL(其他的中间件我没想到)主从,对于单个用户余额来说无法应用分布式架构,可对所有用户来说还是一个分布式架构。比如北京的用户存在在北京,广州的用户存在在广州,两个城市有全量数据,在无法保证P的情况下(比如北京节点挂了),对于部分来说至少广州节点还能用,但对于单个用户来说他可能就完全不能使用了,个体是非分布式的,整体是分布式的。

3:正常的情况下,可以同时存在CA

在不考虑P的情况下(假设不会出现网络分区),不同级别的数据实现CA的方式也可以不一样,比如不重要的数据就使用“数据库同步”的方式(简单但延迟高),重要的数据使用队列的方式(复杂但实时性高)。

4:废弃并不等于什么都不做,需要为分区恢复做好准备。

分区并不是经常性发生,在恢复后,要尽量让系统恢复到CA。麻烦的就是某些数据可能会有冲突,需要想一些策略来同步数据。

和CAP相关的两个概念是ACID和BASE,ACID来是为了保证数据库事务性的,其实没有可比性。网络上有很多比较Redis和MySQL事务的文章,强行比较挺难为人的。这个后续我再参考资料后再分享。

对于BASE来说,它是CAP理论中AP方案的延伸,更具有实践性。

BASE 是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency),核心思想是即使无法做到强一致性(CAP 的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性。

对于基本可用,表示损失部分可用性,保证核心可用,部分和核心需要仔细分辨。

软状态,允许系统存在中间状态,而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。

最终一致性,一定时间后数据最终一致,即达到CA。

BASE 理论本质上是对 CAP 的延伸和补充,更具体地说是对 CAP 中 AP 方案的一个补充

  • 延迟是肯定存在的

  • AP 方案中牺牲一致性只是指分区期间,而不是永远放弃一致性。

这一节写的很精彩,留言更精彩,摘抄一段:

设计分布式系统的两大初衷:横向扩展(scalability)和高可用性(availability)。“横向扩展”是为了解决单点瓶颈问题,进而保证高并发量下的「可用性」;“高可用性”是为了解决单点故障(SPOF)问题,进而保证部分节点故障时的「可用性」。由此可以看出,分布式系统的核心诉求就是「可用性」。这个「可用性」正是 CAP 中的 A:用户访问系统时,可以在合理的时间内得到合理的响应。

为了保证「可用性」,一个分布式系统通常由多个节点组成。这些节点各自维护一份数据,但是不管用户访问到哪个节点,原则上都>应该读取到相同的数据。为了达到这个效果,一个节点收到写入请求更新自己的数据后,必须将数据同步到其他节点,以保证各个节点的数据「一致性」。这个「一致性」正是 CAP 中的 C:用户访问系统时,可以读取到最近写入的数据。

需要注意的是:CAP 并没有考虑数据同步的耗时,所以现实中的分布式系统,理论上无法保证任何时刻的绝对「一致性」;不同业务系统对上述耗时的敏感度不同。

分布式系统中,节点之间的数据同步是基于网络的。由于网络本身固有的不可靠属性,极端情况下会出现网络不可用的情况,进而将网络两端的节点孤立开来,这就是所谓的“网络分区”现象。“网络分区”理论上是无法避免的,虽然实际发生的概率较低、时长较短。没有发生“网络分区”时,系统可以做到同时保证「一致性」和「可用性」。

发生“网络分区”时,系统中多个节点的数据一定是不一致的,但是可以选择对用户表现出「一致性」,代价是牺牲「可用性」:将未能同步得到新数据的部分节点置为“不可用状态”,访问到这些节点的用户显然感知到系统是不可用的。发生“网络分区”时,系统也可以选择「可用性」,此时系统中各个节点都是可用的,只是返回给用户的数据是不一致的。这里的选择,就是 CAP 中的 P。

分布式系统理论上一定会存在 P,所以理论上只能做到 CP 或 AP。如果套用 CAP 中离散的 C/A/P 的概念,理论上没有 P 的只可能是单点(子)系统,所以理论上可以做到 CA。但是单点(子)系统并不是分布式系统,所以其实并不在 CAP 理论的描述范围内。

文章分类
后端
文章标签