Cassandra 中的一致性级别调优

Question

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

假设我有三个节点集群N1、N2、N3。并且我的一致性级别（CL）很弱：即

读取CL=N/2 1=2（在这种情况下），写入CL=Any（alteast 1）

我有一个产品表，例如

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

 product_info : { 'computer': 1}

>

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

客户端1看到1台html" target="_blank">计算机可用

客户端 2 看到 1 台计算机可用

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

product_info：{'计算机'： 0}

现在客户端 2 下订单，因此在 N2 处，表将如下所示：

product_info：{'计算机'： 0}

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

客户端C通过N3访问。现在在N1执行读取，返回0。（因为仲裁至少有两个节点应该响应）N3的值为1，但它的时间戳已过时。因此它将更新其值并向客户端显示没有可用的计算机。这很好

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

Answer 1

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

如果读取一致性写入一致性

假设您的复制因子为3。对于即时一致性和RC=2，您将需要至少2个WC。如果您想要即时一致性并且WC=1，您的RC将需要为3。请注意，这将严重影响可用性，因为一个节点宕机将意味着您无法读取。

即时一致性意味着你将阅读所写的内容。i、 e.成功写入后，没有读取将读取先前的值。但是，这并不妨碍您的应用程序使用以前读取的值。

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

很多时候，特别是在分布式场景中，最好处理故障 - 甚至使其成为商业案例 - 而不是试图阻止任何“坏”的事情发生。像这样的边缘案例是与业务部门交谈并发现隐藏机会的机会：

• 如果我们超额预订一个项目会发生什么？
• 是取消订单更好，还是让客户知道他们的订单不可避免地被推迟了，可能进行销售并给他们礼券。
• 我们能不能给客户一台稍微好一点的电脑，稍微降低一点利润？这可以帮助我们完成销售，让客户满意，并可能给我们带来回报业务。戴尔经常这样做。
• 我们能打电话给客户，解释一下可能的追加销售吗？

当我们发现有问题时，我们甚至可以接受订单并让一个客户知道——我个人在亚马逊看到过这种情况。

如果我们绝对必须防止在销售时出现过度销售，那么也有这样的模式。我们可以使用分布式锁，使用类似木筏甚至动物园管理员的东西来处理卡桑德拉之外的协调。我们还可以用TTL为每个项目实现逻辑锁——用TTL确保杂乱的代码不会弄乱库存。

这实际上取决于你想要多大的保证，以及你愿意为实现这一点而经历多少麻烦。更重要的是，如果不解决这个问题不更赚钱的话。

希望有帮助。