cassandra 中的一致性级别调整

Question

想象一个电子商务应用程序：

假设我有三个 Node cluster N1, N2, N3. 并且我的一致性级别 (CL) 很弱： 那就是

Read CL = N/2+1 = 2 (in this case), Write CL = Any (alteast 1)

我有一个产品表，例如

这是跨三个节点同步的初始数据

 product_info : { 'computer': 1}

1. 现在客户端 A 从 N1 读取信息，客户端 B 从 N1 读取信息 N2

   客户端 1 发现有 1 台计算机可用

   客户端 2 发现有 1 台计算机可用

2. 现在他们俩都去买了，客户 A 先下订单。所以 N1，表格将如下所示：

   product_info : {'computer':0}

3. 现在客户 2 在 N2 下订单，表格看起来像 以下：

   product_info : {'computer':0}

   但实际上客户 2 的订单不应该被处理。

4. 客户端 C 通过 N3 访问。现在在 N1 完成读取 返回 0。（因为 quorum 至少有 2 个节点应该响应） N3 值为 1，但其时间戳已过时。所以它会更新它的 值并向客户显示没有可用的计算机。这个不错

   在这个例子中，弱一致性和强一致性级别都会导致错误的结果，仅仅是因为在客户端A和B加载第一个product_info的时候，数据是同步的。这在 Cassandra 中如何处理？

Answer 1

你没有提到你的复制因子。

如果您的读取一致性 + 写入一致性 > 复制因子，您将立即获得一致性。

假设您的复制因子是 3。为了立即一致性和 RC = 2，您需要至少 2影响可用性，因为一个节点出现故障意味着您无法读取。

即时一致性意味着您将阅读所写的任何内容。即成功写入后，没有读取将读取先前的值。但是，这不会阻止您的应用程序使用它之前读取的值。

在这种情况下，您可以使用轻量级事务。更新.....如果[某些情况。]。这将执行较慢，但可能足以满足您的用例。

很多时候，特别是在分布式场景中，最好处理失败——甚至将其作为商业案例——而不是试图阻止任何“坏事”的发生。像这样的边缘案例是与企业对话并发现隐藏机会的机会：

• 如果我们超量预订商品会怎样？
• 是取消订单更好，还是让客户知道他们的订单不可避免地被延迟了，可能会进行销售并给他们一张礼券。
• 我们能否给客户一台稍微好一点的电脑，但利润会受到轻微影响？这可以帮助我们进行销售，让客户满意，并可能给我们带来回报。戴尔经常这样做。
• 我们可以打电话给客户并解释可能追加销售的情况吗？

我们甚至可以接受订单并在我们发现问题时通知一位客户 - 我在亚马逊上亲眼目睹了这一点。

如果我们绝对必须防止在卖出时出现任何超卖现象，那么也有这样的模式。我们可以使用 raft 甚至 zookeeper 之类的分布式锁来处理 cassandra 之外的协调。我们还可以为每个项目实现带有 TTL 的逻辑锁 - 使用 TTL 来确保杂乱的代码不会弄乱库存。

这实际上取决于您想要的保证字符串，以及您愿意经历多少麻烦来实现这一点。更重要的是，如果不解决它不是更多有利可图。

希望对您有所帮助。