理论先行-CAP定理

你用忙碌送走白昼，笑迎寂静的深夜

并非贪恋繁星的闪耀，而是钟爱默默地拼搏

欢迎关注【架构染色】交流学习

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

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

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

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

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

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

CAP定理(来自网络).png

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

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

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

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

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

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

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

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

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

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

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

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

所以总结来看：

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

组合	结果
CP	满足一致性和分区容错性，也就是说，要放弃可用性。当系统出现分区，为了保证原子性，必须放弃可用性，让请求挂起。
AP	满足可用性和分区容错性，当出现分区，同时为了保证可用性，即使数据尚未完成同步，也必须让节点继续对外服务，这样导致数据不一致