因此，分布式系统理论上不可能选择 CA (一致性 + 可用性)架构，只能选择 CP(一致性 + 分区容忍性) 或者 AP (可用性 + 分区容忍性)架构，在一致性和可用性做折中选择。
①CP - Consistency + Partition Tolerance (一致性 + 分区容忍性)
如上图所示，因为 Node1 节点和 Node2 节点连接中断导致分区现象，Node1 节点的数据已经更新到 y，但是 Node1 和 Node2 之间的复制通道中断，数据 y 无法同步到 Node2，Node2 节点上的数据还是旧数据 x。
这时客户端 C 访问 Node2 时，Node2 需要返回 error，提示客户端 “系统现在发生了错误”，这种处理方式违背了可用性(Availability)的要求，因此 CAP 三者只能满足 CP。
②AP - Availability + Partition Tolerance (可用性 + 分区容忍性)
同样是 Node2 节点上的数据还是旧数据 x，这时客户端 C 访问 Node2 时，Node2 将当前自己拥有的数据 x 返回给客户端了。
而实际上当前最新的数据已经是 y 了，这就不满足一致性(Consistency)的要求了，因此 CAP 三者只能满足 AP。
注意：这里 Node2 节点返回 x，虽然不是一个“正确”的结果，但是一个“合理”的结果，因为 x 是旧的数据，并不是一个错乱的值，只是不是最新的数据。
值得补充的是，CAP 理论告诉我们分布式系统只能选择 AP 或者 CP，但实际上并不是说整个系统只能选择 AP 或者 CP。
在 CAP 理论落地实践时，我们需要将系统内的数据按照不同的应用场景和要求进行分类，每类数据选择不同的策略(CP 还是 AP)，而不是直接限定整个系统所有数据都是同一策略。
另外，只能选择 CP 或者 AP 是指系统发生分区现象时无法同时保证 C(一致性)和 A(可用性)，但不是意味着什么都不做，当分区故障解决后，系统还是要保持保证 CA。
CAP 理论的延伸：BASE 理论BASE 是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency)。
它的核心思想是即使无法做到强一致性(CAP 的一致性就是强一致性)，但应用可以采用适合的方式达到最终一致性。
BA - Basically Available 基本可用
分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
这里的关键词是“部分”和“核心”，实际实践上，哪些是核心需要根据具体业务来权衡。
例如登录功能相对注册功能更加核心，注册不了最多影响流失一部分用户，如果用户已经注册但无法登录，那就意味着用户无法使用系统，造成的影响范围更大。
S - Soft State 软状态
允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。
E - Eventual Consistency 最终一致性
系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
这里的关键词是“一定时间” 和 “最终”，“一定时间”和数据的特性是强关联的，不同业务不同数据能够容忍的不一致时间是不同的。
例如支付类业务是要求秒级别内达到一致，因为用户时时关注;用户发的最新微博，可以容忍 30 分钟内达到一致的状态，因为用户短时间看不到明星发的微博是无感知的。
而“最终”的含义就是不管多长时间，最终还是要达到一致性的状态。
BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充： CAP 理论是忽略延时的，而实际应用中延时是无法避免的。
这一点就意味着完美的 CP 场景是不存在的，即使是几毫秒的数据复制延迟，在这几毫秒时间间隔内，系统是不符合 CP 要求的。
因此 CAP 中的 CP 方案，实际上也是实现了最终一致性，只是“一定时间”是指几毫秒而已。
AP 方案中牺牲一致性只是指发生分区故障期间，而不是永远放弃一致性。
这一点其实就是 BASE 理论延伸的地方，分区期间牺牲一致性，但分区故障恢复后，系统应该达到最终一致性。
数据一致性模型前面介绍的 BASE 模型提过“强一致性”和“最终一致性”，下面对这些一致性模型展开介绍。