目录
CAP 定理
CAP 定理是分布式系统设计中最基础，也是最为关键的理论。它指出，分布式数据存储不可能同时满足以下三个条件。
- 一致性（Consistency）：每次读取要么获得最近写入的数据，要么获得一个错误。
- 可用性（Availability）：每次请求都能获得一个（非错误）响应，但不保证返回的是最新写入的数据。
- 分区容忍（Partition tolerance）：尽管任意数量的消息被节点间的网络丢失（或延迟），系统仍继续运行。
也就是说，CAP 定理表明，在存在网络分区的情况下，一致性和可用性必须二选一。而在没有发生网络故障时，即分布式系统正常运行时，一致性和可用性是可以同时被满足的。
掌握 CAP 定理，尤其是能够正确理解 C、A、P 的含义，对于系统架构来说非常重要。因为对于分布式系统来说，网络故障在所难免，如何在出现网络故障的时候，维持系统按照正常的行为逻辑运行就显得尤为重要。你可以结合实际的业务场景和具体需求，来进行权衡。
言而言之，CAP 理论提到同一时刻只能满足两点需求，永远不存在三者的交集。例如：追求 CA 的 MySQL 就因为缺失了分区耐受性，导致会出现集群区间脑裂重启不成功的问题，决定了它更应该在同一局域网络中工作的瓶颈；再例如：追求 AP 的 Cassandra 虽然没有实现严格一致性，但却在跨地域、跨数据中心的高可用上大放异彩，或者这也是 OpenContrail 当初选型的考量之一，毕竟这很契合其异构云网络集成的愿景。同时 Cassandra 还支持可调节的一致性，也算是做了一些应用场景的适配，聊胜于无。
例如，对于大多数互联网应用来说（如门户网站），因为机器数量庞大，部署节点分散，网络故障是常态，可用性是必须要保证的，所以只有舍弃一致性来保证服务的 AP。而对于银行等，需要确保一致性的场景，通常会权衡 CA 和 CP 模型，CA 模型网络故障时完全不可用，CP 模型具备部分可用性。
-
CA（consistency + availability）：这样的系统关注一致性和可用性，它需要非常严格的全体一致的协议，比如 “两阶段提交”（2PC）。CA 系统不能容忍网络错误或节点错误，一旦出现这样的问题，整个系统就会拒绝写请求，因为它并不知道对面的那个结点是否挂掉了，还是只是网络问题。唯一安全的做法就是把自己变成只读的。
-
CP（consistency + partition tolerance）：这样的系统关注一致性和分区容忍性。它关注的是系统里大多数人的一致性协议，比如：Paxos 算法（Quorum 类的算法）。这样的系统只需要保证大多数结点数据一致，而少数的结点会在没有同步到最新版本的数据时变成不可用的状态。这样能够提供一部分的可用性。
-
AP（availability + partition tolerance），这样的系统关心可用性和分区容忍性。因此，这样的系统不能达成一致性，需要给出数据冲突，给出数据冲突就需要维护数据版本。Dynamo 就是这样的系统。
BASE 理论
BASE 理论是对 CAP 原则中一致性和可用性权衡的结果：
- Basically Available（基本可用）：指分布式系统在出现不可预知故障的时候，允许损失部分可用性，这不等价于系统不可用。
- Soft state（软状态）：指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
- Eventually consistent（最终一致性）：强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
BASE 理论来源于对大规模互联网系统分布式实践的总结，是基于 CAP 原则逐步演化而来的。其最核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统的事务 ACID 特性是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID 特性和 BASE 理论往往又会结合在一起。