CAP

CAP定理是计算机科学中的一个理论结果，它指出，分布式系统不可能同时提供以下三个保证：

1. 一致性：分布式系统中的所有节点在同一时间看到相同的数据；
2. 可用性：对分布式系统的每个请求都会收到响应，但不能保证响应中包含最新版本的数据；
3. 分区容错性：即使网络分区发生，系统仍然可以正常运行，这意味着节点之间的通信可能会丢失或延迟。

CAP定理指出，分布式系统最多可以同时提供三个保证中的两个。这意味着，在设计分布式系统时，需要在一致性、可用性和分区容错性之间进行权衡。 例如，优先考虑一致性的系统可能不如优先考虑可用性的系统那么可用。另一方面，优先考虑可用性的系统可能不会提供与优先考虑一致性的系统相同的一致性水平。了解CAP定理很重要，因为它可以帮助您在设计分布式系统时做出明智的决定，从而使您的系统目标和要求得到满足，避免出现意想不到的问题。

常用软件设计

Zookeeper、Nacos和Eureka都是可用于构建和管理分布式系统的中间件解决方案，它们如何应用CAP定理取决于它们的设计和实现。

• Zookeeper是一种集中式协调服务，提供一致性和分区容错性，但可用性有限。它使用领导者-追随者模型来确保只有一个节点可以对数据进行更改，从而确保一致性。但是，如果领导节点失败，则系统可能在选举新领导者之前不可用。
• Nacos是一个动态服务发现、配置和管理平台，优先考虑可用性和分区容错性，但一致性保证较弱。它使用分布式架构来确保高可用性，并可以自动检测和恢复网络分区。但是，在网络分区的情况下，Nacos可能会暂时提供不一致的数据。
• Eureka是Netflix OSS套件的服务发现和注册组件，提供高可用性和分区容错性，但一致性保证有限。它使用点对点通信模型来确保服务注册表始终可用，即使系统中的单个节点失败。但是，在网络分区的情况下，Eureka可能会暂时提供不一致的数据。

注意

不是所谓的“3 选 2”大部分人解释这一定律时，常常简单的表述为：“一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到”。实际上这是一个非常具有误导性质的说法，而且在 CAP 理论诞生 12 年之后，CAP 之父也在 2012 年重写了之前的论文。

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。简而言之就是：CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。

因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。比如 ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构。

🤔

为啥不可能选择 CA 架构呢？

举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。选择 CP 还是 AP 的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证 CP 。
另外，需要补充说明的一点是： 如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证。

BASE

BASE是一个首字母缩略词，代表基本可用、软状态和最终一致。它是一套用于设计和操作分布式系统的原则，最初由作者兼研究人员Pat Helland在一篇名为《超越分布式事务：一个叛教者的观点》的论文中介绍。

BASE是CAP定理的一个更加宽松的版本，该定理指出，分布式系统不可能同时提供以下三个保证：一致性、可用性和分区容错性。相比之下，BASE认为，可以提供可用性和分区容错性的分布式系统，但不一定总是强一致性。

实践中，BASE系统旨在优先考虑可用性和分区容错性，同时接受数据一致性可能不会总是立即或绝对的。相反，给定足够的时间，数据的一致性最终会得到实现。这使得BASE成为构建需要高可用性的分布式系统的有用模型，即使在网络故障和其他挑战面前也是如此。

怎么理解

1. 基本可用：这意味着系统应该被设计为高可用性，并且应该可以在大部分时间访问存储在系统中的数据。系统应该被设计为以尽可能少的停机时间处理故障和其他挑战。
2. 软状态：这意味着系统的状态应该是动态和灵活的，而不是僵化和不变的。系统应该被设计为适应不断变化的条件并随着时间的推移而发展，而不需要人工干预。
3. 最终一致：这意味着存储在系统中的数据可能不会立即一致，但是给足够的时间，一致性最终会被实现。这允许系统在网络故障和其他挑战面前继续运行。

了解BASE的深层次内容，也很重要的是要理解在构建以可用性和分区容错为优先的分布式系统时所做的权衡。例如，这些系统可能比优先一致性的系统更复杂，更难设计和操作。此外，最终一致性的使用可能会导致数据的暂时不一致，这可能需要以符合系统特定要求的方式处理。

要深入了解BASE，可以阅读Pat Helland的原始论文，并探索使用BASE模型的真实世界示例。此外，可能有助于研究NoSQL数据库和其他类型的分布式系统的设计和实现，这些系统优先考虑可用性和分区容错性而不是一致性。

BASE vs CAP

CAP和BASE原则都用于描述构建和操作分布式系统所涉及的权衡。但是，它们从略有不同的角度来解决这一挑战。

1. CAP定理指出，分布式系统不可能同时提供这三个保证。相反，设计师必须进行权衡，并将这三个保证中的两个优先于第三个。相比之下，BASE原则对一致性持更宽松的看法。BASE原则优先考虑可用性和分区容错性，但接受数据一致性可能不会总是立即或绝对的。相反，给定足够的时间，数据的一致性将最终被实现。

总之，BASE和CAP的区别在于，BASE接受最终一致性作为高可用性和分区容错性的权衡，而CAP优先考虑三个保证中的两个。根据系统的具体要求和权衡，两种原则都可以用于设计和操作分布式系统。
2. 就实际而言，在设计和构建分布式系统时，CAP定理可以帮助指导决策，迫使设计师明确他们的权衡。例如，如果系统需要高度一致性和可用性，它可能不得不容忍一定程度的分区。另一方面，如果分区容忍度是主要关注点，则系统可能不得不牺牲一些一致性或可用性保证。

3. BASE原则提供了一种更宽松的一致性观点，可用于高可用性和分区容忍度是主要关注点，最终一致性是可接受的系统。在这些系统中，数据可能在节点之间暂时不一致，但最终，给足了足够的时间，数据将收敛到一致的状态。

值得注意的是，CAP定理和BASE原则不是绝对的规则，而是思考权衡的指南。实践中，系统的具体要求和约束将影响所做的权衡。 总的来说，理解CAP定理和BASE原则对于设计和构建可扩展、弹性的分布式系统，以满足应用程序及其用户的具体需求，是非常有价值的。