CAP原则和BASE理论
CAP原则和BASE理论
概要
分布式系统最大的难点,就是各个节点的状态如何同步。CAP定理是这方面的基本定理。
所谓CAP,指Consistency(一致性)、Avaliability(可用性)、Partition Tolerance(分区容错性),最多只能同时满足两个特性,三者不可兼得。即要么AP,要么CP,要么AC,但是不存在CAP。
一、CAP原则
1、Partition Tolerance(分区容错性)
是指分布式系统在遇到网络分区或节点故障时,仍然能够对外提供满足一致性(Consistency)或可用性(Avaliability)的服务。
一般来说,分区故障无法避免,这是因为在分布式系统中,网络通信是不可靠的,可能会出现网络分区导致节点之间无法直接通信的情况。因此,分区容错性是保证系统稳定性和可用性的关键因素之一。
说明:如果一个系统在面临网络分区时无法保持可用性和一致性,那么就意味着系统会在网络分区时变得不可用,这与分布式系统的设计目标相违背。因此,CAP 原理指出,在分布式系统中,分区容错性是必须要满足的基本条件之一。
补充一下:什么是分区?
在分布式系统中,不同的节点分布在不同的子网络中,由于一些特殊的原因,这些子节点之间出现了网络不通的状态,但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域,这就是分区。
2、Consistency(一致性)
“all nodes see the same data at the same time”
所有节点在同一时间看到的数据完全一致的,这就是分布式系统的一致性。用户更新操作后能读取到更新后的数据,对分布式系统来说,问题是数据的更新如何同步到整个系统,以保证数据最终一致。
3、Avaliability(可用性)
“Reads and writes always succeed”
是指系统能够在有限的时间内对请求做出响应,而不是返回错误或者超时。
说明:在面对网络分区(P),系统仍然能够保证对客户端请求的响应。因此,如果请求发生超时或错误,系统无法满足可用性要求。
二、Consistency和Avaliability的矛盾
可以从两方面去看为什么一致性和可用性不能同时成立
1)因为可能会出现通信失败,不满足分区容错性。
2)假设在满足分区容错性的同时,保证一致性,那么在写操作时,就必须要锁定其他节点的读写操作,不满足可用性。保证可用性,那么就不能锁定读写操作,不满足一致性。因此无法同时满足CAP,系统设计时,需要选择一个目标。
三、CAP的取舍
1)CA - 单点集群
这等于是放弃系统的扩展性,系统不再是分布式的,有违分布式系统设计的初衷。
2)CP - 满足一致性、分区容忍性的系统,通常性能不是特别高。
在数据一致性要求比较高的场合(譬如:zookeeper,Hbase,PXC) 是比较常见的做法,一旦发生网络故障或者消息丢失,就会牺牲用户体验,等恢复之后用户才逐渐能访问。
3)AP - 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。
服务注册中心Eureka组件和NoSQL中的Cassandra 就是这种架构。跟CP一样,放弃一致性不是说一致性就不保证了,而是逐渐的变得一致。
四、解决方案——BASE
BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简写,BASE是对CAP中一致性和可用性权衡的结果。它是来源于对大规模互联网分布式实践的总结,是基于CAP理论演化来的。下面简单地解释一下。
1、基本可用
所谓基本可用,是指分布式系统在出现故障时,允许损失部分可用性,以保证系统基础运转仍然正常。这在实际操作中并不少见,
比如:
1)正常情况下,数据库需要在200ms内返回查询结果,但由于故障,使得响应时间延长到了2s,即响应的延迟增加了;
2)在电商大促高峰(特别是秒杀)时,为了维护整个系统的稳定性,部分订单会不成功,用户会被引导至降级页面,即牺牲部分功能。
2、软状态
软状态也称为弱状态,是指允许系统中的数据存在中间状态,并且该中间状态不影响系统的可用性。更直白点说,就是分布式系统在不同节点之间进行数据同步的过程中允许有一定的不同步性。
3、最终一致性
最终一致性是指系统中的所有副本在经过一段时间的同步之后,最终总能够达到一致的状态。它是BASE的终极目标,也是任何分布式系统在实践中必须达到的目标。
核心思想:即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。
说明:BASE理论是CAP原则的一个演变,它不要求数据强一致性,放低了要求,保证系统基本可用,数据最终一致
五、总结
对于多数大型互联网应用的场景,集群规模越来越大,节点越来越多,所以节点故障、网络故障是常态,因此分区容错性也就成为了一个必要条件。那么只能在C和A之间进行取舍。
1)在什么场合,一致性高于可用性?
例如银行的转账系统,C必须保证,出现故障时,宁可停止服务也要保证C,这个场景就是一致性高于可用性。
2)在什么场合,可用性高于一致性?
例如发布页面到CDN,页面的更新不特别强调一致性,因此允许用户加载到老版本的页面,另一些用户加载到新版本的页面,这个场景就是可用性高于一致性。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步