学习分布式不得不会的ACP理论

作者 : 开心源码 本文共5172个字,预计阅读时间需要13分钟 发布时间: 2022-05-11 共127人阅读

原创:?Hollis

2000年7月,加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后,麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证实了CAP。之后,CAP理论正式成为分布式计算领域的公认定理。

无论你是一个系统架构师,还是一个普通开发,当你开发或者者设计一个分布式系统的时候,CAP理论是无论如何也绕不过去的。本文就来详情一下究竟什么是CAP理论,如何证实CAP理论,以及CAP的权衡问题。

? ? ? ? ? ? ? ? ?CAP理论概述

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

读者需要注意的的是,CAP理论中的CA和数据库事务中ACID的CA并完全是同一回事儿。两者之中的A都是C都是一致性(Consistency)。CAP中的A指的是可使用性(Availability),而ACID中的A指的是原子性(Atomicity),切勿混为一谈。

CAP的定义

Consistency 一致性

一致性指“all nodes see the same data at the same time”,即升级操作成功并返回用户端完成后,所有节点在同一时间的数据完全一致,所以,一致性,说的就是数据一致性。分布式的一致性

对于一致性,可以分为从用户端和服务端两个不同的视角。从用户端来看,一致性主要指的是多并发访问时升级过的数据如何获取的问题。从服务端来看,则是升级如何复制分布到整个系统,以保证数据最终一致。

一致性是由于有并发读写才有的问题,因而在了解一致性的问题时,肯定要注意结合考虑并发读写的场景。

从用户端角度,多进程并发访问时,升级过的数据在不同进程如何获取的不同策略,决定了不同的一致性。

三种一致性策略

对于关系型数据库,要求升级过的数据能被后续的访问都能看到,这是强一致性。

假如能容忍后续的部分或者者一律访问不到,则是弱一致性。

假如经过一段时间后要求能访问到升级后的数据,则是最终一致性。

CAP中说,不可能同时满足的这个一致性指的是强一致性。

Availability 可使用性

可使用性指“Reads and writes always succeed”,即服务一直可使用,而且是正常响应时间。

对于一个可使用性的分布式系统,每一个非故障的节点必需对每一个请求作出响应。所以,一般我们在衡量一个系统的可使用性的时候,都是通过停机时间来计算的。

通常我们形容一个系统的可使用性时,我们说淘宝的系统可使用性可以达到5个9,意思就是说他的可使用水平是99.999%,即全年停机时间不超过?(1-0.99999)*365*24*60 = 5.256 min,这是一个极高的要求。

好的可使用性主要是指系统能够很好的为使用户服务,不出现使用户操作失败或者者访问超时等使用户体验不好的情况。一个分布式系统,上下游设计很多系统如负载均衡、WEB服务器、应使用代码、数据库服务器等,任何一个节点的不稳固都可以影响可使用性。

Partition Tolerance分区容错性

分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”,即分布式系统在遇到某节点或者网络分区故障的时候,依然能够对外提供满足一致性和可使用性的服务。

分区容错性和扩展性紧密相关。在分布式应使用中,可能由于少量分布式的起因导致系统无法正常运转。好的分区容错性要求能够使应使用尽管是一个分布式系统,而看上去却如同是在一个可以运转正常的整体。比方现在的分布式系统中有某一个或者者几个机器宕掉了,其余剩下的机器还能够正常运转满足系统需求,或者者是机器之间有网络异常,将分布式系统分隔未独立的几个部分,各个部分还能维持分布式系统的运作,这样就具备好的分区容错性。

简单点说,就是在网络中断,消息丢失的情况下,系统假如还能正常工作,就是有比较好的分区容错 性。

? ? ? ? ? ? ?CAP的证实

如上图,是我们证实CAP的基本场景,网络中有两个节点N1和N2,可以简单的了解N1和N2分别是两台计算机,他们之间网络可以连通,N1中有一个应使用程序A,和一个数据库V,N2也有一个应使用程序B2和一个数据库V。现在,A和B是分布式系统的两个部分,V是分布式系统的数据存储的两个子数据库。

在满足一致性的时候,N1和N2中的数据是一样的,V0=V0。在满足可使用性的时候,使用户不论是请求N1或者者N2,都会得到立即响应。在满足分区容错性的情况下,N1和N2有任何一方宕机,或者者网络不通的时候,都不会影响N1和N2彼此之间的正常运作。

如上图,是分布式系统正常运转的流程,使用户向N1机器请求数据升级,程序A升级数据库Vo为V1,分布式系统将数据进行同步操作M,将V1同步的N2中V0,使得N2中的数据V0也升级为V1,N2中的数据再响应N2的请求。

这里,可以定义N1和N2的数据库V之间的数据能否一样为一致性;外部对N1和N2的请求响应为可使用行;N1和N2之间的网络环境为分区容错性。这是正常运作的场景,也是理想的场景,然而现实是残酷的,当错误发生的时候,一致性和可使用性还有分区容错性,能否能同时满足,还是说要进行取舍呢?

作为一个分布式系统,它和单机系统的最大区别,就在于网络,现在假设一种极端情况,N1和N2之间的网络断开了,我们要支持这种网络异常,相当于要满足分区容错性,能不能同时满足一致性和响应性呢?还是说要对他们进行取舍。

假设在N1和N2之间网络断开的时候,有使用户向N1发送数据升级请求,那N1中的数据V0将被升级为V1,因为网络是断开的,所以分布式系统同步操作M,所以N2中的数据仍旧是V0;这个时候,有使用户向N2发送数据读取请求,因为数据还没有进行同步,应使用程序没办法立即给使用户返回最新的数据V1,怎样办呢?

有二种选择,第一,牺牲数据一致性,保证可使用性。响应旧的数据V0给使用户;

第二,牺牲可使用性,保证数据一致性。阻塞等待,直到网络连接恢复,数据升级操作M完成之后,再给使用户响应最新的数据V1。

这个过程,证实了要满足分区容错性的分布式系统,只能在一致性和可使用性两者中,选择其中一个。

? ? ? ??CAP权衡

通过CAP理论及前面的证实,我们知道无法同时满足一致性、可使用性和分区容错性这三个特性,那要舍弃哪个呢?

我们分三种情况来阐述一下。

CA without P

这种情况在分布式系统中几乎是不存在的。首先在分布式环境下,网络分区是一个自然的事实。由于分区是必然的,所以假如舍弃P,意味着要舍弃分布式系统。那也就没有必要再探讨CAP理论了。这也是为什么在前面的CAP证实中,我们以系统满足P为前提论述了无法同时满足C和A。

比方我们熟知的关系型数据库,如My Sql和Oracle就是保证了可使用性和数据一致性,但是他并不是个分布式系统。一旦关系型数据库要考虑主备同步、集群部署等就必需要把P也考虑进来。

其实,在CAP理论中。C,A,P三者并不是平等的,CAP之父在《Spanner,真时,CAP理论》一文中写到:

假如说Spanner真有什么特别之处,那就是谷歌的广域网。Google通过建立私有网络以及强大的网络工程能力来保证P,在多年经营改进的基础上,在生产环境中可以最大程度的减少分区发生,从而实现高可使用性。

从Google的经验中可以得到的结论是,无法通过降低CA来提升P。要想提升系统的分区容错性,需要通过提升基础设备的稳固性来保障。

所以,对于一个分布式系统来说。P是一个基本要求,CAP三者中,只能在CA两者之间做权衡,并且要想尽办法提升P。

CP without A

假如一个分布式系统不要求强的可使用性,即容许系统停机或者者长时间无响应的话,即可以在CAP三者中保障CP而舍弃A。

一个保证了CP而一个舍弃了A的分布式系统,一旦发生网络故障或者者消息丢失等情况,就要牺牲使用户的体验,等待所有数据一律一致了之后再让使用户访问系统。

设计成CP的系统其实也不少,其中最典型的就是很多分布式数据库,他们都是设计成CP的。在发生极端情况时,优先保证数据的强一致性,代价就是舍弃系统的可使用性。如Redis、HBase等,还有分布式系统中常使用的Zookeeper也是在CAP三者之中选择优先保证CP的。

无论是像Redis、HBase这种分布式存储系统,还是像Zookeeper这种分布式协调组件。数据的一致性是他们最最基本的要求。一个连数据一致性都保证不了的分布式存储要他有何使用?

在我的Zookeeper详情(二)——Zookeeper概述一文中其实详情过zk关于CAP的思考,这里再简单回顾一下:

ZooKeeper是个CP(一致性+分区容错性)的,即任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具有容错性。但是它不能保证每次服务请求的可使用性,也就是在极端环境下,ZooKeeper可能会丢弃少量请求,消费者程序需要重新请求才能取得结果。ZooKeeper是分布式协调服务,它的职责是保证数据在其管辖下的所有服务之间保持同步、一致。所以就不难了解为什么ZooKeeper被设计成CP而不是AP特性的了。

AP wihtout C

要高可使用并允许分区,则需放弃一致性。一旦网络问题发生,节点之间可能会失去联络。为了保证高可使用,需要在使用户访问时可以马上得到返回,则每个节点只能使用本地数据提供服务,而这样会导致全局数据的不一致性。

这种舍弃强一致性而保证系统的分区容错性和可使用性的场景和案例非常多。前面我们详情可使用性的时候说到过,很多系统在可使用性方面会做很多事情来保证系统的全年可使用性可以达到N个9,所以,对于很多业务系统来说,比方淘宝的购物,12306的买票。都是在可使用性和一致性之间舍弃了一致性而选择可使用性。

你在12306买票的时候一定遇到过这种场景,当你购买的时候提醒你是有票的(但是可能实际已经没票了),你也正常的去输入验证码,下单了。但是过了一会系统提醒你下单失败,余票不足。这其实就是先在可使用性方面保证系统可以正常的服务,而后在数据的一致性方面做了些牺牲,会影响少量使用户体验,但是也不至于造成使用户流程的严重阻塞。

但是,我们说很多网站牺牲了一致性,选择了可使用性,这其实也不精确的。就比方上面的买票的例子,其实舍弃的只是强一致性。退而求其次保证了最终一致性。也就是说,尽管下单的瞬间,关于车票的库存可能存在数据不一致的情况,但是过了一段时间,还是要保证最终一致性的。

对于多数大型互联网应使用的场景,主机众多、部署分散,而且现在的集群规模越来越大,所以节点故障、网络故障是常态,而且要保证服务可使用性达到N个9,即保证P和A,舍弃C(退而求其次保证最终一致性)。尽管某些地方会影响用户体验,但没达到造成使用户流程的严重程度。

适合的才是最好的

上面详情了如何CAP中权衡及取舍以及典型的案例。孰优孰略,没有定论,只能根据场景定夺,适合的才是最好的。

对于涉及到钱财这样不能有一丝退让的场景,C必需保证。网络发生故障宁可中止服务,这是保证CA,舍弃P。比方前几年支付宝光缆被挖断的事件,在网络出现故障的时候,支付宝就在可使用性和数据一致性之间选择了数据一致性,使用户感受到的是支付宝系统长时间宕机,但是其实背后是无数的工程师在恢复数据,保证数数据的一致性。

对于其余场景,比较普遍的做法是选择可使用性和分区容错性,舍弃强一致性,退而求其次用最终一致性来保证数据的安全。这其实是分布式领域的另外一个理论——BASE理论。我们下一篇文章再来详情。

总结

无论你是一个架构师,还是一个普通开发,在设计或者开发分布式系统的时候,不可避免的要在CAP中做权衡。需要根据自己的系统的实际情况,选择最适合自己的方案。

原文链接:https://mp.weixin.qq.com/s?__biz=MzI3NzE0NjcwMg==&mid=2650121696&idx=1&sn=d8043efa332f3f76b96f7067754f2f01&chksm=f36bb8c1c41c31d7ca5f6bd02246bdb68ea49dd178c0b007fc0ff2f11d1a625113b5cccdc908&mpshare=1&scene=1&srcid=0717wxnP5u8Lms2hxtwBV2zL&pass_ticket=lby7qRd6A1IgqeHfoTl7n18GOHYvLeJJyDNxzRmyXxY%3D#rd

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 学习分布式不得不会的ACP理论

发表回复