Cassandra LWT 可靠性状态

这个问题：

在 2016 年因 Won't Fix 关闭表明，至少在当时，Cassandra 轻量级事务根本不起作用，至少对于概述的（基本和常见）用例。

引用：

*使用版本 ID（执行条件更新）和事务 ID（确定 WTE 是否真的成功，代表当前线程/事务/操作）仍然不起作用。

线程 A：读取版本 1

线程 A：将版本 1 更新为 2，交易 ID 为 ABC，并将账户余额设置为 $0+$100=$100，成功应用更新但仍收到 WTE。

线程 B：读取版本 2

线程 B：将版本 2 更新为 3，交易 ID 为 XYZ，并将账户余额设置为 $100+500=$600，赢得比赛，看不到任何 WTE。话题B：很开心！

线程A：再次尝试，这次读取版本3，看到版本3比之前的版本2大，现在检查事务id，发现也不同..

线程 A 如何知道它的更新失败或成功？因为在它进行更新和再次读取记录之间，其他人已经更新了它。

此时，线程 A 可能会假设它失败并再次尝试并在余额中再添加 100 美元，从而导致帐户中出现的金额超出预期。或者它可能会选择放弃交易，但如果 WTE 实际上是由于超时而不是争用，则余额将比预期少 100 美元。*

我的问题是，这种情况在 2021 年有变化吗？我是否正确地得出结论（例如 Yugabyte 断言）Cassandra 轻量级事务根本不完全可靠，无论使用何种仲裁设置？

LWT“不完全可靠”（在我看来）的断言有点苛刻。它有一些挑战，但我与许多在生产中成功使用 LWT 的组织合作。

我还认为您引用的工单中的示例不是 LWT 的“基本和常见用途”。事实上，这是一个极端的用例。

LWT 最常见的用例之一是用户帐户配置。考虑一个允许用户选择用户名的网络应用程序。这是表的示例架构：

df.sort_values(['id','date'])

为了防止 2 个或更多用户选择相同的用户名：

df['sort']=pd.PeriodIndex(df['date'].str.split('.').str[::-1].str.join('-'),freq='Q').to_timestamp()
df=df.sort_values(['id','sort']).drop('sort',1)

对于这个用例，LWT 工作得非常好，因为如果插入失败很容易恢复——你可以重新运行查询，如果用户名已经存在并且被用户使用，它将是一个空操作.

但是票据中的示例是一个极端情况，因为您不能简单地重新运行查询——它不是幂等的。这并不意味着所有 LWT 都已损坏。它只是在这个特定示例中不起作用，您将需要一种不同的机制来处理银行分类帐用例。干杯！