首页 文章

cassandra中的一致性级别调整

提问于
浏览
2

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

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

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

我有一个产品表,如

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

product_info : { 'computer': 1}
  • 现在,客户端A从N1读取信息,客户端B从N2读取信息

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

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

  • 他们现在都去购买客户A首先下订单 . 所以N1,表格如下所示:

product_info : {'computer':0}

  • 现在客户端2在N2处进行订单,表格如下所示:

product_info : {'computer':0}

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

  • 客户端C通过N3访问 . 现在读取在N1处完成,返回0.(因为仲裁至少有2个节点应该响应)N3的值为1,但其时间戳已过时 . 所以它将更新其值并向客户显示没有可用的计算机 . 这很好

在此示例中,弱和强一致性级别都将导致错误的结果,这仅仅是因为在客户端A和B加载第一个product_info时,数据是同步的 . 怎么能在Cassandra处理?

1 回答

  • 3

    您没有提到复制因素 .

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

    假设您的复制因子是3.为了立即一致性和RC = 2,您将需要WC至少为2.如果您想要立即一致性并且WC = 1,则您的RC将需要为3.注意,这将严重影响可用性,因为一个节点下降意味着你无法阅读 .

    立即一致意味着您将阅读已写入的内容 . 即,在成功写入之后,没有读取将读取先前的值 . 但是,这并不会阻止您的应用程序使用它之前读过的值 .

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

    通常情况下,特别是在分布式场景中,最好处理失败 - 甚至将其作为商业案例 - 而不是试图防止任何“坏”发生 . 像这样的边缘案例是与业务交流的机会,并找到隐藏的机会:

    • 如果我们超量预订项目会怎样?

    • 最好是取消订单,或让客户知道他们的订单不可避免地延迟,可能会进行销售并给他们一张礼券 .

    • 我们能否为客户提供稍微好一点的电脑,从而轻微获利?这可以帮助我们进行销售,满足客户并可能为我们提供回报业务 . 戴尔经常这样做 .

    • 我们可以打电话给客户并解释可能向上销售的情景吗?

    我们甚至可以接受订单,让一个客户知道我们何时发现存在问题 - 我个人在亚马逊上看到过这个问题 .

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

    这实际上取决于你想要什么样的保证金,以及你不能解决它多少麻烦're willing to go through to achieve this. And more so, if it's .

    希望有所帮助 .

相关问题