CAP
Definition
CAP 也即 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性）
CAP Theorem 指出，对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个：
- Consistency（一致性）：所有节点的数据副本的内容相同；
- Availability（可用性）：非故障的节点在合理的时间内返回合理的响应；
- Partition Tolerance（分区容错性）：分布式系统中部分分区出现故障时（也即出现网络分区），整个系统仍然能够对外提供服务。
Network Partition（网络分区） 分布式系统中，多个节点之间的网络本来是连通的，但是由于某些故障，某些节点之间不连通了，整个网络就分成了几块区域，这就是网络分区
Not 2 in 3
当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后，P 是前提，决定了 P 之后才有 C 和 A 的选择，即分区容错性（Partition tolerance）我们是必须要实现的。
简而言之：CAP 理论中 P 是一定要满足的，在此基础上，只能再满足 C 或 A。
因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或 AP 架构。如 ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构。
选择 CP 还是 AP 的关键在于当前的业务场景，没有定论。
为什么不可能选择 CA 架构？ 当系统出现网络分区后，某个节点在进行写操作，若为了保证 C，就必须禁止其他节点的读写操作，这就违背了 A；若为了保证 A，其他节点也能正常读写，就违背了 C。
如果网络分区正常的话，也即无需保证 P 的时候，C 和 A 能同时保证。因此，如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。
BASE
Definition
BASE 也即 Basically Available（基本可用）、Soft-state（软状态）和 Eventually Consistent（最终一致）。
BASE 理论是对 CAP 中的 C 和 A 权衡的结果。
核心思想
即便无法做到强一致性，每个应用都可以根据自身特点以适当方式来时系统达到最终一致性。
也就是说以牺牲数据的一致性来满足系统的可用性，当系统中的部分数据不可用或者不一致时，仍需要保持系统整体主要可用。
BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 架构的补充。AP 架构是在系统发生分区的时候放弃 C，而不是永远放弃 C。在分区故障恢复后，系统应该达到最终一致性，这一点就是 BASE 理论延伸的地方。
BASE 三要素
基本可用
分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等价于系统不可用。
- 响应时间上的损失：正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3s。
- 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。
软状态
允许系统中的数据存在中间状态（也即初先了数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，也即允许系统的不同节点的数据副本之间进行数据同步的过程中存在延时。
最终一致性
系统中所有的数据副本，在经过一段时间的同步后，最终能达到一个一致的状态。不需要实时保证数据的强一致性。
分布式一致性的 3 个级别： 1. 强一致性：能立刻读出写入的最新数据； 2. 弱一致性：不一定可以读到最新写入的数据，也不保证多久之后能读到最新的数据，只是尽量保证某个时刻达到数据一致的状态； 3. 最终一致性：系统保证在一定时间内达到数据一致的状态。
实现最终一致性的具体方式：
- 读时修复：系统在读取数据时，检测数据的不一致，并修复。
- 写时修复：系统在写入数据时，检测数据的不一致，并修复。
- 异步修复：系统通过定时对账来检测副本数据的一致性，并修复。
写时修复的性能消耗较低。
总结
ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 架构的延伸。
