NoSQL：MongoDB 或 BigTable 并不总是“可用”意味着什么

阅读内森·赫斯特的著作NoSQL 系统视觉指南 http://blog.nahurst.com/visual-guide-to-nosql-systems，他包括CAP三角形：

• C一致性
• A可用性
• P分区容差

随着 SQL Server 成为AC系统，MongoDB 是一个CP system.

这些定义来自加州大学伯克利分校教授 Eric Brewer 在 PODC 2000 上的演讲 http://www.julianbrowne.com/article/viewer/brewers-cap-theorem（分布式计算原理）：

可用性

可用性意味着——服务可用 （完全运行或不运行如上所述）。当你购买你想要的书时 得到响应，而不是有关该网站的浏览器消息 不善于交流。 Gilbert & Lynch 在他们的 CAP 定理证明中提出 优点是，当你需要的时候，可用性往往会抛弃你 最重要的是——网站往往会在繁忙时段宕机，正是因为它们 很忙。可用但未被访问的服务是无服务 对任何人都有好处。

在 MongoDB 或 BigTable 的上下文中，系统不“可用”意味着什么？

您是否要进行连接（例如通过 TCP/IP），而服务器没有响应？您是否尝试执行查询，但查询从未返回 - 或者返回错误？

它有什么作用mean不可用？

在这种情况下，可用性意味着如果出现网络分区，客户端连接到的服务器可能无法保证客户端期望的（或系统配置提供的）一致性级别。

假设在一个假设的分布式系统中有 3 个节点 A、B 和 C。 A、B 和 C 各自在自己的服务器机架中运行，它们之间有 2 个交换机：

[Node A] <- Switch #1 -> [Node B] <- Switch #2 -> [ Node C ]

现在假设所述系统已设置为保证任何写入操作在被视为已提交之前都会到达至少 2 个节点。现在，假设交换机 #2 被拔掉，并且某个客户端连接到节点 C：

[Node A] <- Switch #1 -> [Node B]                 [ Node C ] <-- Some client

该客户端将无法发出一致性写入，因为分布式系统当前处于分区状态（即节点 C 无法联系足够多的其他节点来保证所需的 2 节点一致性）。

我想补充一点，一些 NoSQL 数据库允许非常动态地选择 CAP 属性。例如，Cassandra 允许客户端指定在每次写入提交之前必须写入的服务器数量。到单个服务器的写入是“AP”，到仲裁（或所有）服务器的写入更多是“CA”。

编辑-来自下面的评论：

在 MongoDB 中，您只能在副本集中进行主/从配置。这意味着 AP 与 CP 的选择是由客户端在查询时做出的。客户端可以指定slaveOk，它将从任意选择的从站（可能有陈旧数据）中读取：mongodb.org/display/DOCS/…。如果客户端不能接受过时的数据，则不要指定slaveOk，查询将转到主服务器。如果客户端无法到达主服务器，那么您将收到错误。我不确定这个错误到底是什么。