分布式 CAP 原理

用户头像
dj_cd
关注
发布于: 2020 年 07 月 14 日

在一个分布式系统中,数据一致性(Consistency)、系统可用性(Availability)以及分区容错性(Partition Tolerance)这三个分布式系统指标最多只能同时实现其中的两个,三者不可兼得,这就是CAP原理,也被称作CAP定理。

1. 数据一致性(Consistency)

Every read receives the most recent write or an error.

一致性是说,每次请求获取的数据都是最新的数据或者返回错误,而不应该返回过期的数据,这就要求每个区的数据是一致的。

当区之间的通信出现问题时:

  • 如果返回错误,系统的可用性(Availability)就有问题(系统不能提供正常数据);

  • 如果各区返回自己的数据,数据就有可能不一致。

例如:

保证系统可用性(Availability)



  • 当客户端对v0​修改成v1​,为了满足系统可用性,Partition1会将v0​​修改成v1​,客户端得到最新数据v1​,后面接入到Partition1的请求,得到的也是最新的数据v1​;

  • 由于Partition1与Partition2之间无法通信,Partition2仍是数v0​,当请求接入到Partition2时,得到的就是过期的数据v0​,数据不一致。

保证数据一致性(Consistency)



  • 由于Partition1与Partition2之间无法通信,为了数据能够保持一致,对于客户端的修改请求,返回错误,系统暂时处于不可用状态,但是Partition1和Partition2的数据仍然保持一致是v0​。

2. 系统可用性(Availability)

Every request receives a (non-error) response, without the guarantee that it contains the most recent write.

可用性是说,每次的请求都应当能够接收到一个响应,而不是返回一个错误或者是失去响应,但是并不保证数据是最新的。

3. 分区容错性(Partition Tolerance)

The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

大多数分布式系统都分布在多个子网络中,每个子网络就是一个区(Partition),而分区之间的通信可能失败,当出现这种情况时系统应当是仍然可以操作的。

通常认为,分区间的网络通信是不可靠的,很有可能通信失败,所以在做系统设计时,必须要考虑分区容错。CAP原理告诉我们,由于分区容错无法避免,那么数据的一致性(Consistency)和系统可用性(Availability)无法同时满足。

也就是说,当出现消息丢失或延迟时:

  • 要保证数据的一致性,在这段时间系统的可用性就无法满足,否则数据就会出现不一致;

  • 要想系统可用同时数据还要一致,那么就只能有一个区(Partition),然而对于分布式系统来说这点显然是不可能的。

4. CAP总结

为什么在分布式系统中,数据一致性(Consistency)与系统可用性(Availability)不能同时成立,答案也很简单,就是子网络区(Partition)之间网络的不可靠性,即会出现分区容错。

所以在设计分布式系统时,就需要权衡数据一致性(Consistency)和系统可用性(Availability),根据实际的业务场景设置一个合理目标。

5. 解决方案——BASE理论

BASE理论是由eBay架构师提出的。BASE是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网分布式系统实践的总结,是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统打到最终一致性。



既然数据一致性(Consistency)和系统可用性(Availability)不能够同时满足,做到数据的强一致性(Strong Consistency),那么就需要一种权衡方案,所以这时候BASE理论就诞生了。

BASE理论是基于对大规模互联网系统分布式实践的实践总结,基于 CAP 定理逐步演化而来的。每个应用都可以根据自身的业务特点,采用适当的方式使系统达到最终一致性(Eventual consistency)。

BASE:全称:Basically Available(基本可用),Soft state(软状态),和 Eventually consistent(最终一致性)三个短语的缩写,来自 ebay 的架构师提出。

5.1 基本可用(Basically Available)

假设系统出现了故障,但是还可以提供服务,相比较正常情况:

  • 请求响应时间上的损失,即原本可以在1s内返回结果,而基本可用可在2s内返回结果

  • 功能上的损失,即正常情况下业务可以顺利开展,而基本可用一方面可以是部分功能受损,另一方面可以是功能降级

5.2 软状态(Soft State)

软状态是相对硬状态而言的,硬状态是指系统中各节点上的数据都是一致的,而软状态则允许系统中的数据存在中间状态,而这些中间状态并不影响系统的整体可用性,也就是说在分布式系统中多个节点的数据允许存在数据延迟。

5.3 最终一致性(Eventually Consistent)

最终一致性是指系统能够保证数据在没有新的更新操作的情况下,数据最终一定能够达到一致的状态。

对于数据的软状态来说,不能一直都处于软状态,必须有个时间限制,即在时限到达后,各节点的数据应该能够保持数据的一致性。而这个时限与网络延迟、系统负载、数据复制方案设计等因素有关。

在项目实践中,最终一致性主要分为以下5种情况:

  • 因果一致性(Causal Consistency)

因果一致性是指,在节点A数据更新后通知了节点B,那么节点B之后对该数据的访问和修改都是基于A更新后的值;而与节点A无因果关系的节点C的数据访问则没有这样的限制。

  • 读己之所写(Read Your Writes)

在节点A更新了一个数据后,在节点A上访问到的该数据一定是更新之后的最新值,而不会是历史值,其实这也算是一种因果一致。

  • 会话一致性(Session Consistency)

会话一致性是对系统数据的访问过程限定在了一个会话当中,在一个有效的会话中实现“读己之所写”,即数据更新后,客户端在一个会话中读取到的值始终是该数据的最新值。

  • 单调读一致性(Monotonic Read Consistency)

单调读一致性是指如果一个节点返回了一个数据的某个值后,在后续的任何数据访问,该节点都不应该返回比该数据更旧的值。

  • 单调写一致性(Monotonic Write Consistency)

单调写一致性是指,一个系统需要保证来自同一节点的写操作能够被顺序地执行。

用户头像

dj_cd

关注

还未添加个人签名 2019.08.09 加入

还未添加个人简介

评论

发布
暂无评论
分布式 CAP 原理