理论先行-CAP定理

一、分布式系统的需求与困境

是不是会有大佬（产品？老板？）对你所负责的分布式系统提出以下三点要求：

1. 既要：系统高可用
2. 又要：各系统数据一致且实时可见
3. 还要：系统具有集群容错能力

这些要求看似简单，但当你仔细思考时就会发现很让人头疼、无法全部实现；如果你还不理解，我们举个例子，如防疫时期的静态化管理：

1. 人停工企业停产（失去可用性）
2. 全城全面核酸，统一采用核酸码平台，实时统筹管理数据（保证数据的一致性）
3. 人被限制在小区内活动、交换物资，小区间禁止互通（分区容错）

经历过的人应该了解，当我们要满足2、3时，就必须牺牲1；或许你也尝试思考过如何破局但又困惑无解；不过无需自责，不仅是你会觉得困难，其他人也一样，因为违背了CAP定理。

二、CAP 定理解惑

在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），定理讨论了两个互相矛盾的请求，到达彼此连接不通的两个不同的分布式节点 的时候的处理方案。

CAP定理 指出对于一个分布式计算系统来说，不可能同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

CAP定理(来自网络).png

有这么一种说法：以实际效果而言，系统若不能在时限内完成同步，达到数据一致性；就意味着发生了分区的情况，必须就当前操作在一致性和可用性之间做出选择。

三、一致性（Consistency）

一致性是说，所有节点访问同一份最新的数据副本；即一致性保证了无论将数据写入哪一个节点，其它的节点都能实时同步到这个新数据，而随后无论从哪个节点读到的都是最新的数据。如下图所示：

CAP定理-一致性(来自网络).png

如果节点之间数据同步有异常，那就必须先解决掉同步的问题，挂起所有的请求，等待数据同步完成后才响应，那么会出现以下几种情况：

• 请求在等待很久后才得到了正确结果
• 写入数据异常
• 读取数据异常

CAP定理-一致性(来自网络)​.png

四、可用性（Availability）

可用性是说，如果有节点异常了，只要向其它无异常的节点发送请求，总能正常的收到响应数据，但数据可以不是最新的，如下图所示：

CAP定理-可用性(来自网络)​.png

五、分区容错性（Partition tolerance）

先说分区是什么，在分布式系统中，不同的节点分布在不同的子网络中，若因一些网络故障，出现了子网络之间不通的情况，但每个子网络内是正常的；这样一个完整的系统就被切分成了若干个相对孤立的区域，这就是分区。

对于分布式系统来说，在遇到任何网络故障而导致分区时，仍然能够对外提供具有一致性或可用性的服务。也就是说会分区之间即使无法同步数据，也能对外提供服务。

CAP定理-分区容错性(来自网络)

六、反推CAP定理

借用一个示例通过反证法来梳理CAP定理，如整个系统由服务节点A、B组成，节点之间通过网络通信，当节点 A 进行更新数据操作的时候，需要同时更新节点 B 的数据。

集群同步示例(来自网络)

假设同时满足CAP这三个特性，由于具有分区容错能力，则可以切断 A、B两个节点间的通信

1. 当A、B节点通信断开后，因无法通信，一致性就无法满足，但A、B都还能对外提供服务，满足可用性
2. 若要强行满足一致性，就必须让A、B节点不再提供服务，等A、B节点间的网络通信故障修复后才继续提供服务，但这就放弃了可用性。

所以总结来看：

• 若要一致性：则必须保障节点间数据同步，同步执行期间数据被锁定、请求被挂起，会导致请求失败或超时，破坏了可用性
• 若要可用性：则节点间数据在同步时不允许数据被锁定、请求被挂起，这就破坏了一致性。

七、一致性的取舍

总结来说，在分布式系统中，首先必须要满足P，因为是多节点，一定要会遇到并要容忍分区错误，而C或A则需要根据具体场景进行取舍。

当系统既要提供可用性，而又不能放弃一致性的情况下，通常会因场景差异而调整对一致性的要求，而差异点体现在时效性上如：

• 强一致性
  任意时刻，任意节点都能读取到最新的数据
• 弱一致性
  可能无法在明确限定的时间内读到最新的数据
• 最终一致性
  是一种弱一致性的特殊形式，系统保证在过了某个时间窗口后，数据将达到完全一致的状态，而之后的读取到的一定是新数据。

分布式业务系统实现中，多数场景中会选择牺牲一致性来换取可用性。而所谓的牺牲其实就是不追求强一致，而选择弱一致或最终一致。

本文转载自微信公众号「架构染色」，可以通过以下二维码关注。转载本文请联系联系【架构染色】公众号作者。