0

首先，我知道在 Cassandra 上不能混合使用 LWT 和非 LWT 操作是有限制的。

根据我在我们的申请中的观察，这种限制的原因之一是：

从 java driver 3.0 开始，正常插入会使用客户端生成的时间戳，而 LWT 插入会使用服务器端的时间戳，而 Cassandra 使用的是 last-write-win 策略。

我知道使用 LWT（4 往返 / paxos / 等）对性能的影响，但我们的案例是我们将 DC 级分布式锁放在 Cassandra 上。所以在尝试获取锁的时候，我们使用了LWT插入，但是为了加快锁的性能，我们在释放锁的时候使用了普通的删除。然后我们面临混合使用 LWT 和非 LWT 操作导致的数据损坏。也就是说，我们的删除成功了，但是时间戳更早，所以它没有生效。

然后我们的第一个修复是使用 writetime() 函数运行 LOCAL_QUORUM 查询来检索写入时间戳，添加 1 毫秒，并在删除时使用“USING TIMESTAMP”设置它。然后我们意识到它仍然不起作用，因为使用 LOCAL_QUORUM 检索到的时间戳似乎不是 LWT 插入的数据的最终写入时间。尽管如此，我们还是使用更早的时间戳处理删除。

所以实际上我有3个问题：

  1. LWT 插入的数据是否在不同副本中具有不同的时间戳，这些时间戳实际上是在 LWT paxos 的第 3 步（提议/接受）期间从 Cassandra 节点生成的？

  2. 对 LWT 插入的数据执行具有一致性级别 LOCAL_QUORUM 的查询是否将响应写入时间视为其 ACK 中的最新写入时间？例如，LWT 插入的 3 个副本有 3 个不同的时间戳，LOCAL_QUORUM 查询检索其中 2 个，并使用这 2 个的最新时间戳作为响应的写入时间？

  3. 如果我们必须坚持这样做（通过 LWT 插入然后正常删除），我们是否可以使用 LOCAL_SERIAL 一致性级别和 writetime() 函数来检索时间戳，并将其用作正常删除的时间戳以确保删除有效？

或者，我们唯一的选择是对我们的用户锁使用 LWT 插入和 LWT 删除，还是放弃我们在 Cassandra 上的分布式锁？

欢迎大家讨论，提前致谢~

4

0 回答 0