1.CAP原则又称CAP定理
指的是在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)这三个基本需求,最多只能同时满足其中的2个,CAP原则的精髓就是要么AP,要么CP,要么AC,但是不存在CAP。
2. 一个栗子🌰
如图所示,假设一个分布式系统正常运转的流程
2.1、Consistency 一致性
一致性指的是所有节点在同一时间的数据完全一致。对用户来说,就好像是操作了同一个数据库的同一个数据一样。
如果用户修改了G1的值v1,但是随后有可能向 G2 发起读操作,由于 G2 的值没有发生变化,因此返回的是 v0。G1 和 G2 读操作的结果不一致,这就不满足一致性了。
2.2、Availability 可用性
可用性指服务一直可用,而且是正常响应时间。用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器,只要收到请求,就必须告诉用户,到底是 v0 还是 v1,否则就不满足可用性。(无论请求是否正常,即使发生了异常也要有响应,不能吞了请求)。
2.3、Partition tolerance 分区容错性
分区容错性指在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。比如G1节点和G2节点,一台服务器放在中国,另一台服务器放在美国,这就是两个区,它们之间可能无法通信。一般来说,分区容错无法避免,因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们,剩下的 C 和 A 无法同时做到。(某一个区的服务不能正常接收请求的时候,必须能有其他区能接替故障区的服务接收到请求提供正常的响应)。
3、可用性(Availability)和分区容错性(Partition tolerance)的区别:
可用性是指接收到了请求,但是没有响应任何结果(吞了请求),不给其他区的服务尝试继续提供服务的机会(比如SpringBoot设置接口访问超时时间)。
分区容错性是指某个区的服务不能正常工作时,其他区的服务可以尝试继续提供服务(比如使用eureka等注册中心时,服务中的某台ServiceA重启无法处理请求时,另一台ServiceB可以继续提供服务)。
4. CAP原则权衡
通过CAP理论,我们知道无法同时满足一致性、可用性和分区容错性这三个特性,那要舍弃哪个呢?
一致性和可用性,为什么不可能同时成立?答案很简单,因为可能通信失败(即出现分区容错)。
如果保证 G2 的一致性,那么 G1 必须在写操作时,锁定 G2 的读操作和写操作。只有数据同步后,才能重新开放读写。锁定期间,G2 不能读写,没有可用性不。
如果保证 G2 的可用性,那么势必不能锁定 G2,所以一致性不成立。
综上所述,G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性,那么无法保证所有节点的可用性;如果追求所有节点的可用性,那就没法做到一致性。
4.1. CA without P
如果不要求P(不允许分区),则C(强一致性)和A(可用性)是可以保证的。但其实分区不是你想不想的问题,而是始终会存在,因此CA的系统更多的是允许分区后各子系统依然保持CA。
4.2. CP without A
如果不要求A(可用),相当于每个请求都需要在Server之间强一致,而P(分区)会导致同步时间无限延长,如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
4.3. AP wihtout C
要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。
5、BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简写。
BASE是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的结论,是基于CAP定理逐步演化而来的,其核心思想是即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。基本可用:指分布式系统在出现不可预知故障的时候,允许损失部分可用性。