1.CAP 理论
CAP 原则又称为 CAP 定理,指的是在一个分布式系统中,Consistency(一致性)
、Availability(可用性)
、Partition tolerance(分区容错性)
这三个基本需求,最多只能同时满足其中的两个。
那么 CAP 分别是什么?
- 一致性(C):数据在多个副本之间能够保持一致的特性
- 可用性(A):系统提供的服务一直处于可用的状态,每次请求都能获得正确的响应
- 分区容错性(P):分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务
什么是分区?
在分布式系统中,不同的节点分布在不同的子网络中,由于一些特殊的原因,这些子节点之间出现了网络不通的状态,但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域,这就是分区。
为什么 CAP 三者不可兼得?
首先,在分布式系统中,分区是不可避免的,因此分区容错性(P)是一定要满足的。接下来再看看,在满足分区容错的基础上,能不能同时满足一致性(C)和可用性(A)。
假如现在有两个分区 N1
和 N2
,N1
和 N2
分别有不同的分区存储 D1
和 D2
,以及不同的服务 S1
和 S2
。
- 在满足一致性(C)时,
N1
和N2
的数据要求值一样,D1 = D2
- 在满足可用性(A)时,无论访问
N1
还是N2
,都能获取及时的响应
现在有这样的场景:
- 用户访问了
N1
,修改了D1
的数据 - 用户再次访问,但此时请求落在了
N2
,此时D1
和D2
的数据不一致
接下来:
- 保证一致性(C):此时
D1
和D2
数据不一致,要保证一致性就不能返回不一致的数据,此时可用性(A)就无法保证 - 保证可用性(A):立即响应,可用性得到了保证,但是此时相应的数据和
D1
不一致,此时一致性(C)就无法保证
可以看出,在满足分区容错性(P)的前提下,一致性(C)和可用性(A)是矛盾的
CAP 原则权衡
CAP 三者不可兼得,那么就必须做一些权衡取舍
- CA:如果不要求P(不允许分区),则 C(强一致性)和 A(可用性)是可以保证的。但是对于分布式系统,分区是客观存在的,其实分布式系统理论上是不可选 CA 的
- CP:如果不要求 A(可用),相当于每个请求都需要在 Server 之间强一致,而 P(分区)会导致同步时间无限延长,如此 CP 也是可以保证的,很多传统的数据库分布式事务都属于这种模式
- AP:要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性,现在众多的 NoSQL 都属于此类
在微服务分布式架构中,常见的可作为注册中心的组件有:zookeeper
、eureka
、nacos
- zookeeper 保证的是 CP, 任何时刻对 zookeeper 的读请求都能得到一致性的结果,但是, zookeeper 不保证每次请求的可用性比如在 leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的
- eureka 保证的则是 AP, eureka 在设计的时候就是优先保证 A (可用性)。在 eureka 中不存在什么 leader 节点,每个节点都是一样的、平等的。因此 eureka 不会像 zookeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。 eureka 保证即使大部分节点挂掉也不会影响正常提供服务,只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的
- nacos 不仅支持 CP 也支持 AP
2.BASE 理论
BASE 是 Basically Available(基本可用) 、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。
BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果,其来源于对大规模互联网系统分布式实践的总结,是基于 CAP 定理逐步演化而来的,它大大降低了我们对系统的要求。
BASE 理论的核心思想是:即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。
BASE 理论的三个特性
基本可用
加入系统出现了不可预知的故障,允许损失部分可用性(当然也不能完全不可用)
损失的这部分可用性指的是什么?
- 响应时间上的损失:正常情况下的搜索引擎 0.5 秒即返回给用户结果,而基本可用的搜索引擎可以在 2 秒作用返回结果
- 功能上的损失:在一个电商网站上,正常情况下,用户可以顺利完成每一笔订单。但是到了大促期间,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面
软状态
软状态指允许系统中的数据存在中间状态(CAP 理论中的数据不一致),并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性
最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。
3.CAP vs BASE:什么时候用哪个?
- 涉及支付交易等业务,比如银行系统,需要保证数据的强一致性,选用 CP 模型。例如 mysql 和 zk 都是选用的 CP 模型
- 设计社交媒体,比如微博、朋友圈点赞,可以采用 BASE 理论,保证高可用性和最终一致性。一些 NoSQL 数据库采用的就是 BASE 理论
其实 CAP 理论更像是一个原则,而 BASE 理论更偏向于实际工程应用。现代分布式系统大多基于 CAP 和 BASE 做出合理权衡,以实现最优的性能与体验。
参考:https://www.cnblogs.com/three-fighter/p/15293310.html