CAP定理，也称为布鲁尔定理（Brewer's Theorem），是由加州大学伯克利分校的计算机科学家Eric Brewer提出的。CAP是指一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）三个系统属性。在一个分布式系统中，CAP定理声明：
一致性
无论客户端连接到哪个节点，它们总是会同时看到相同的数据，这就是我们所说的一致性。为了实现这一点，每次将数据写入一个节点时，都必须立即将其发送或复制到系统中的所有其他节点，然后才能认为写入已“成功完成”。
可用性
即使网络中的一个或多个节点不可用，所有发出数据请求的客户端都会得到响应。这就是我们谈论的可用性。另一种表达方式是，分布式系统中的每个操作节点都将会为每个请求提供合法的答案。
分区容错性
分布式系统内部的通信中断称为分区。这可以被认为是系统中两个节点之间丢失或暂时延迟的链路。术语“分区容错性”是指尽管构成系统的各个节点之间的通信出现任意数量的故障，但仍必须维持集群的功能。
CAP定理指出，在任何给定的时刻，一个分布式系统只能满足上述三个保证中的两个。换言之，如果一个系统已经必须满足分区容错性（P），那么它必须在一致性（C）和可用性（A）之间进行权衡。
例如，当一个网络分区故障发生时，系统管理员可能需要选择：
- 放弃一致性（C）以保持可用性（A）和分区容错性（P），这种情况下，系统会继续处理事务，但是结果可能不一致。
- 或者放弃可用性（A）以保持一致性（C）和分区容错性（P），这样的话，在故障消除前，系统不会执行任何可能违反数据一致性规则的操作。
不同 NoSQL 数据库的 CAP
NoSQL 数据库是在分散网络上运行的应用程序的最佳选择。与其垂直可扩展的 SQL（关系）前身相比，NoSQL 数据库在设计上具有水平可扩展性和分布式性。这意味着它们能够在由多个链接节点组成的开发网络上快速扩展。
NoSQL 数据库现在根据它们提供的两个 CAP 标准进行分类，它们是：
CP 数据库提供一致性和分区容错性，但会牺牲其可用性。如果任意两个节点之间发生分区，系统需要将不一致的节点停止（即使其不可访问），直到分区被纠正。
AP 数据库提供可用性和分区容错性，但代价是数据的一致性。当分区发生时，网络中的所有节点继续可访问，但更靠近分区开头或结尾的节点可能提供比其他节点更旧版本的数据。（一旦分区问题得到纠正，AP 数据库通常会重新同步节点，以纠正系统中可能引入的任何不一致情况。）
CA 数据库确保系统中所有节点的数据一致且可访问。但是，如果系统中任意两个节点之间存在分区，则无法完成此任务，从而无法提供容错功能。
由于分区在分布式系统中是不可避免的，因此我们特意将 CA 数据库类型放在列表的最后。因此，虽然理论上可以讨论CA分布式数据库的概念，但实际上，这样的数据库根本不存在。
包括 PostgreSQL、MySQL、SQLServer在内的各种关系数据库都提供一致性和可用性，并且它们可以跨多个节点进行复制以进行分布式部署，但它们都不是真正的分布式数据库。
CAP 定理和 MongoDB
MongoDB 中的数据存储为 BSON（二进制 JSON）文档，使其成为常见的 NoSQL 数据库管理系统。它广泛用于大规模、实时、分布式应用。
MongoDB 是一种 CP 数据存储，因为它能够解决网络分区问题，同时以牺牲可用性为代价保持数据一致，正如 CAP 定理所描述的那样。
在 MongoDB 中，只能有一个主节点来处理给定副本集的所有写入。副本集中的辅助节点复制主节点的事务日志并使用它来更新自己的数据副本。默认情况下，客户端从主节点读取，但他们可以通过设置读取首选项来更改此设置。
如果原节点宕机，具有最新操作日志的Secondary节点将被提升为主角色。一旦所有从属节点赶上新的主节点，集群将再次变得可访问。由于在此期间没有客户端可以发送写请求，因此数据在整个网络中同步。
CAP 定理 (AP) 和 Cassandra
Apache软件基金会开发的 Cassandra，是一个免费的开源 NoSQL 数据库。以宽列数据库的形式进行分布式数据存储。由于其无主设计，Cassandra 不存在像 MongoDB 那样的单点故障。
Cassandra 是一个 AP 数据库，因为它满足一致性、可用性和分区容错性 (CAP) 的部分但不是全部要求。由于缺少主节点，Cassandra 集群中的所有节点始终保持运行状态至关重要。另一方面，Cassandra 通过允许客户端随时写入任何节点并及时解决差异来提供最终一致性。
Cassandra 具有“修复”功能，可以帮助节点赶上其对等节点，因为数据只会在网络分裂的情况下变得不一致，但差异会很快得到纠正。另一方面，持续的可用性在注重高性能的系统中尤为重要，在某些情况下牺牲一致性是值得的。
结论
如果你正在创建基于微服务的分布式项目，了解 CAP 定理可以帮助你选择正确的数据库。例如，如果你可以接受最终（而不是严格）一致性，但需要快速迭代数据模型并水平增长，那么像 Cassandra 或 Apache CouchDB 这样的 AP 数据库可能会满足你的需求并简化部署。另一方面，如果你的应用程序注重数据的可靠性（就像在电子商务或支付服务中一样），那么像 PostgreSQL 这样的关系数据库可能是最佳选择。
