分布式理论CAP

image.png

一、什么是CAP理论

CAP理论,指的是在一个分布式系统中,Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性),不能同时成立。

CAP理论是分布式架构中提出来的一种设计思想模型,全称是由ConsistencyAvailabilityPartition Tolerance三个词组成,通过单词便可知其意,其实,这三个词分别代表着不同的含义,在做分布式架构设计时,只能在其三中选其二,并不能同时满足三个思想模型。
分布式理论CAP三者的定义如下:

  • 一致性(C ) :保证所有节点上的数据始终同步。
  • 可用性(A ):无论响应成功还是失败,每个请求都是有效的,并不会发生网络超时等情况。
  • 分区容错性(P ) :系统内部(某个节点的分区)中丢失消息,系统也应该可以继续提供服务。一致性和可用性是分布式系统的固有属性。

二、CAP分布模型

CAP理论分布模型是基于区域约束来实现的,包含C(一致性)、A(可用性)、P(分区容错性)三者的关系所形成的理论模型。那么CAP理论模型中这三者是怎么联系起来的呢?由于分布式理论CAP特性,只能同时满足三个领域中的两个,所以,我们在思考过程中也知道,可形成三种情况供选择。CAP分布模型图构建和三者之间的关系如下图:
image.png

三、CAP核心思想

CAP理论是分布式架构设计中心思想,其核心思想是在分布式架构体系下,基于什么样的场景构建稳定健壮安全可用的软件系统。那么多年来,CAP理论在互联网界广为人知,被称为“帽子理论”。 这是Eric Brewer教授在2000年举办的ACM研讨会上提出的著名猜想一致性、可用性、分区容错性(partition-tolerrity )。 2003年,MIT的Gilbert和Lynch正式证明这三者确实不可兼得。 而且CAP被认为是分布式领域的重要理论,被很多人认为是分布式系统设计的金律

四、CAP解决了什么问题

通过对分布式理论CAP认知,我们都应该了解到软件系统在分布式架构场景下会引发哪些问题,而这些问题的背后又是用什么技术手段方法去解决的呢?那么我们就带着这个问题去寻找答案,切入点如下图:
image.png

我这边画了一张便于理解的系统架构链路分析图,其实,在图中已经解答了我上面所提出的问题。那么图中都隐含了什么呢?下面通过 3 个场景去解答,如下:
1、如何保证数据一致性
首先,需要先理解一致性的概念,指的是在主数据多副本同步过程中实时保持数据是一致的。CAP理论中所描述的一致性是强一致性的,但在分布式系统场景下是很难保证强一性,通过图中的主库和从库之间一旦发生延迟超时等其它情况,则无法保证数据的强一致性。而为了避免这种问题,后面又提出了不能保证强一致性的同时,可以保证数据的最终一致性,并不要求实时数据一致的情况。其实,在这里有引入了一个理论,那就是Base理论模型,对于这个理论模型下一篇再深入的进行说明。
2、如何保证系统可用性
那么在分布式架构里面为什么要保证系统可用性,提出的一点就是随着业务量的增长,单系统可承受的压力是受限的,为了解决这个问题,引入了分布式架构多副本、集群模式,这样就解决了系统单点问题。通过图中蓝框部分实现了系统集群化和系统架构高可用,避免因为图中红框里面部分系统中断,造成系统不可用状态。在这里面也隐含的表达了Base理论里面的基本可用特征。
3、为什么要选择分区容错性
在解答这个问题之前,我们先要理解分区容错性的概念,也就是什么是分区容错性。分区容错性是在系统通信层面,能够避免系统的某个分区网络分区出现问题,导致系统中断不可用状态。那么了解了什么是分区容错性以后,我们接着看图中的蓝框里面的三个系统,在分布式架构下,通常一个请求是由多系统协作完成的。若此时B、C系统内部网络通信发生局部异常,则会直接使系统网络通信之间中断并导致不可用,而在有分区容错性的保证下则会对系统网络通信异常分区隔离,并不会影响整个系统的不可用,所以在分布式架构下分区容错性是必选的,那么对于我们的选择的就只有CA之间做权衡了。

五、CAP应用场景

CAP理论证明限制在原子读写场景中,声明不支持数据库事务等场景。 将分区的容错性总结为关于网络环境的描述,而不是以前的独立条件。

相对于CAP理论应用场景,一般情况下可根据实际业务场景做选择,但我想提的一点就是主要应用于分布式架构当中,为什么这么说呢?因为你的业务足够简单且单应用架构中,像这种场景下是应用不到的。那么CAP一般都适用于哪些场景呢?通过CAP分布模型(实际业务情况下)分为如下三种情况:

  • CA:该方案保证的是系统一致性可用性,但损失了分区容错性,在基于此方案的前提下,若业务系统构 建于分布式架构场景下,则在系统服务之间的网络通信分区发生中断,某一块分区出现损坏时,会 导致整个业务系统不可用状态,不管你的系统是否保证了高可用。因为在该方案下,只能在系统网 络层面去保证网络的分区问题。由于采用该方案的业务系统几乎很少,弊端也明显,所以我们在做业 务架构中做出正确的选择,避免出现不可挽回的损失
  • CP:保证了分布式架构中数据的一致性,该方案适用于对于一致性要求苛刻的业务场景下,会选择此方 案。例如 zookeeper内部实现机制就是基于分布式一致性的,能够保证数据的存储不丢失,但某一 时刻出现服务中断,则会导致服务不可用状态。那么大家可能会有疑问,集群化不就行了,但是你要考 虑的前提是单集群里面只有一个leader,若leader服务不可用了,选举情况下也会有一段时间不可用 状态,所以像采用这种方案的情况下只能保证数据一致性,并不能保证服务可用性,但可以尽量做到缩 短选举的时间,间接的保证服务可用性。
  • AP:保证了服务在分布式架构中可用性,现在大部分业务系统都是基于此方案去实现的,若是你的业务系 统是对可用性要求比较高,则可采用该方案去实现。那么随着业务量的增长,系统可用性的要求也越 来越高,只要保证有一台服务可用,便可处理内外部请求。但是可用性得到了保证,数据一致性也是 尤为重要的,对于数据一致性要求没那么高的情况下,可以间接的保证数据最终一致性,该特性是基于 Base理论模型中提出来的,也是为了解决分布式架构下一致性问题的致命缺陷。

六、总结

分布式理论CAP是基于系统之间的不断重现精进的,CAP并不是普遍的普通原理指导思想,它只适用于原子读写NoSQL系统架构设计场景,而不适用于数据库系统。现在的分布式系统也不是多年前的简单系统。 如今,分布式系统具有可扩展性、自动化等诸多特性,想成为架构师不仅需要理解 CAP 问题,还需要在设计开发系统时拓展视野。

猜你喜欢

转载自blog.csdn.net/weixin_43322048/article/details/127652235