弱一致性用例（为什么要使用它）？

Question

CP = 每次读取都会收到最近的写入或错误。

弱一致性= 写入后，读取可能会或可能不会看到它。 采用尽力而为的方法。

（ 来源）

如果我理解正确，在 CAP 定理中，我们在可用性 (AP) 和一致性 (CP) 之间进行权衡，因此我们必须在它们之间进行选择。

弱一致性是一种一致性模式，所以为了实现它，我需要传递可用性。

但是模式定义声明了“尽力而为”，这意味着它无法验证“接收到最近的写入”原则。

所以我的问题是 - 为什么要使用它？ 我将选择最大努力一致性而不是可用性的用例是什么？

Answer 1

CAP 定理表明，在网络分区期间，您的系统作为一个整体应该如何表现：

• 要么一致但不高可用
• 或可用但不高度一致

（ 来源）

美联社

即使存在临时网络分区，这会阻止节点之间的正确同步/复制，您仍然允许新的写入操作。 因此，某些节点可能具有比其他节点更新的值。 从消费者的角度来看，这意味着两次后续读取可能会返回不同的值。

CP

即使有一个 temporal.network 分区阻止了节点之间的正确同步/复制，您也只允许读取操作或不允许任何操作。 无论您的系统是否支持降级模式，您都可以切换到只读模式，否则您将变得（作为一个系统）完全不可用。

网络问题后 AP 与 CP

• 在 AP 的情况下，您需要在固定网络分区后在节点之间执行同步
• 在 CP 的情况下，您可以在修复网络分区后重新执行写入操作

不同的 NOSQL 数据库系统更喜欢可用性（如 Cassandra、DynamoDb），而其他数据库系统更喜欢一致性（如 Redis、MongoDb）。 根据您的要求，您必须选择合适的数据库系统来支持您的需求。

Answer 2

你可以通过付出沟通成本来获得强一致性。 在强一致性系统中，您需要对所有需要大量通信的客户端请求进行完全排序（想想 Paxos 或 PBFT）。

但是，有些应用不需要强一致性，这种情况下为什么要付出通信成本呢？

在这种情况下，更多的通信意味着响应客户端请求的延迟增加。

示例 1：如果您是一家银行，并且您正在清算交易。 在这种情况下，您希望具有很强的一致性。 否则，您可能会蒙受经济损失。

Example-2：假设你是一个博客系统，作者可以发布博客条目，之后他们可以编辑它们。 如果作者编辑了他的条目，但某些用户看到的是旧版本而不是最新版本。 我想这不是世界末日，也没有任何其他含义。

因此，如果您的应用程序需要强一致性，您应该拥有它。 否则，拥有它可能会毫无用处地增加客户端请求的延迟。