我在网上阅读了很多文章，但仍然对为什么 Mongo CP、Cassandra AP、RDBMS CA 感到困惑？将解释我的理解和查询。
蒙哥
考虑一个场景，我有一个主人和两个奴隶。考虑
- 写请求到达并转到主控。
- 它仅在主服务器上提交，但主服务器在写入从服务器之前关闭（崩溃）
- 直到master连任，写请求需要等待，系统不可用
- 一旦前一个节点（在步骤 2 中崩溃的节点）返回，该节点的待处理写入将被写回从属节点。这称为最终一致性。
根据我的理解，由于第 3 步和第 4 步，Mongo 被称为 CP，其中 C 代表最终一致。正确的 ？
卡桑德拉
这里没有主/从模型，每个节点都基于分片键接收其共享写入和读取请求。
- 写请求到达任意节点（称为协调节点）。
- 协调节点根据分片键重定向到其中一个节点
- 它被提交，但节点在写入其他复制节点之前关闭（崩溃）。
- 再次使用相同的分片键写入请求，现在协调节点立即将其重定向到副本节点（崩溃节点的副本）
- 一旦前一个节点（在步骤 3 中崩溃的节点）返回，该节点的待处理写入将被写回副本节点。所以 cassandra 似乎最终也是一致的？
第 4 步解释了为什么 cassandra 具有高可用性，但第 5 步也描述了它最终的一致性。因此，根据我的理解，cassandra 提供了最终一致性和可用性。那为什么说它不提供 Consitency 呢？
CAP 定理中的一致性是指强一致性，即每次读取都会收到最近的写入或错误。默认情况下，MongoDB 驱动程序将所有读取和写入定向到副本集的主节点，这是高度一致的。
CAP 定理断言，分布式系统必须在网络分区的情况下在一致性和可用性之间进行选择。MongoDB 的副本集方法使用单个主节点来实现写入一致性 (CP)，而 Cassandra 的复制策略则倾向于写入可用性 (AP)。网络分区不可能实现强一致性，因为如果分区的两侧更新相同的数据，可能会发生冲突。为了保持写入可用性，AP 数据库系统需要解决冲突的解决方案，这是与最终一致性分开的考虑因素。
然而，CAP 是对现实世界行为的简化：MongoDB 和 Cassandra 都具有可调整的读写一致性级别。例如：MongoDB 有写关注来确定写操作所需的确认级别，读偏好将请求路由到副本集的成员，读关注来控制从副本集读取的数据的新近性、一致性和隔离属性，以及分片部署。
CAP Theorem 的作者 Eric Brewer 在 2012 年重新审视了这一点，并进行了更细致的解读：CAP 十二年后：“规则”如何改变。
没有主节点就没有写入，但副本集仍然具有读取可用性。MongoDB 3.6 添加了Retryable Writes功能，可帮助应用程序更好地处理副本集选举和瞬态网络错误。
如果 MongoDB 副本集中的主节点不可用，如果有合格的辅助节点和法定成员投票，则副本集中的其余成员将选举一个新的主节点。在您的示例中，投票多数将是您的副本集的 2/3 成员。前主节点接受的任何未写入大多数副本集成员的写入都将被回滚（保存到磁盘），因此前主节点从与当前主节点历史一致的状态恢复同步。