ACID 事务即将进入 Apache Cassandra：这就是我们兴奋的原因

An extraordinary computer science breakthrough called Accord is bringing globally available, general-purpose ACID transactions to the next Cassandra release

让我们先把最好的部分拿出来。 ACID 事务即将进入 Apache Cassandra。

全球可用的通用事务，其工作方式与 Cassandra 的工作方式相同。这不是精美印刷或旧技术应用的一些技巧。

这要归功于 Apple 和密歇根大学的一个团队在计算机科学领域取得的非凡突破，名为Accord 。它将通过打开新的用例帮助 Cassandra 改变我们对数据的看法。

对于那些不了解 Cassandra 项目及其功能的来龙去脉的人来说，这意味着什么。没有什么比将应用程序投入生产的速度更重要的了。但是想要将 Cassandra 的规模、弹性和传奇的多数据中心支持用于金融交易等事情的开发人员必须在他们的应用程序中编写一堆复杂的解决方法。与使用 Oracle 之类的工具相比，权衡取舍非常重要。

与雅阁？没有取舍。 Cassandra 现在将支持一切让它变得惊人的东西，同时将事务支持转移到数据库，显着降低代码复杂性。

观察者之眼

数据库系统具有可靠存储数据和可供查询等基本功能。管理数据的变化并不总是数据库的功能。在许多 NoSQL 系统的情况下，变更管理的负担被推迟到用户身上。数据变化的观察者是谁分配了排他性的重要性。

假设重点是按照给定的方式积累数据。在这种情况下，观察者必须知道数据已被接收并持久存储——例如，股票代码数据，其中每个数据点都是唯一且累积的。没有必要排他性。

在更敏感的操作中，数据更改的观察者需要感觉他们是唯一使用数据库的进程。这是计算机科学中的一个概念，称为“隔离”；它是 ACID 中的“I”（原子性、一致性、隔离性、持久性）。

一个典型的例子是银行转账，其中钱从一个银行账户中扣除，然后添加到另一个银行账户中——正是按照这个顺序。观察过程需要排他性以避免其他过程进行可能导致不一致或意外的更改。

意外情况包括无意中允许从低于 0 美元的账户转账。

隔离保证一次只有一个进程可以进行更改，如果两个进程竞争相同的数据，其中一个将不得不等待另一个完成。

拥抱你的懒惰

开发人员需要使用他们可以信任的系统快速行动。近 50 年来，ACID 事务一直是数据库系统中信任的黄金标准。开发人员根据需求进行权衡，有时会导致他们使用不支持 ACID 事务的系统。

对于 NoSQL 系统，权衡偏见历来倾向于在牺牲交易的同时扩大规模和正常运行时间。

将 ACID 事务引入 Cassandra 旨在减少权衡取舍。 Cassandra 在线性扩展方面已经享有盛誉，同时在最坏的情况下也能保持正常运行时间。

当您需要一个数据库来支持互联网可以提供的内容时，Cassandra 一直是您的选择。毫不奇怪，对交易的需求一直是开发人员权衡冲突的根源。

我们能达成共识吗？

在分布式系统中，较大集群中的每个成员节点可以独立行动或需要与其他节点协调。在“嘿，我们都需要就某事达成一致”的交易中，计算机科学家称之为共识，开发这些协议是一个持续改进的领域。

Paxos是 Cassandra 于 2013 年为“轻量级交易”采用的历史悠久的共识协议。

轻量级，因为它确保单个分区数据更改在事务中被隔离，但多个表或分区不是一个选项。此外，Paxos 需要多次往返才能获得共识，这会产生大量额外的延迟和关于何时在应用程序中使用轻量级事务的细则。

Raft协议是作为下一代协议来替代 Paxos 的，Etcd、CockroachDB 和 DynamoDB 等多个系统都采用了它。 It reduced round trips by creating an elected leader.

Cassandra 在这种方法中的缺点是领导者不会跨越数据中心，因此需要多个领导者（请参阅Spanner ）。

选举领导者也违反了 Cassandra 的“无共享”原则，并且会对处理故障提出新的要求。

如果节点出现故障，则必须选举新的领导者。

其他数据库——例如 FaunaDB 和 FoundationDB——已经走上了试图通过减少到单个全球领导者来解决多领导者问题的路线，如Calvin 论文中所述。

因为这些是为具有不同要求的其他数据库构建的，所以在这些情况下使用的方法无法满足 Cassandra 期望的故障模式标准。

Cassandra 将故障视为运行广泛的分布式系统的一部分。一个或多个节点离线不应导致性能快速下降或可用性问题。我们需要一种不同的方法。

我们达成协议了吗？

对于 Cassandra 项目可接受的内容，我们可能会非常固执己见。我们的标准是坚持关于分布式系统应该如何运行的核心信念。在跨一个或多个数据中心运行多个节点时，应始终保持性能和扩展性。我们可能要求很高，但这正是 Cassandra 成为众多组织选择的原因。

共识协议的先前迭代解决了问题的不同部分，但每个迭代都提出了一个会违反 Cassandra 的某些价值观的权衡。据说下一个重大突破距离上一个突破两篇论文。在这种情况下，这篇论文是Accord ，它在消除权衡方面做了很大的努力。

Accord 解决了之前共识协议中未解决的两个问题：我们如何才能拥有全球可用的共识并在一次往返中实现？第一个新颖的机制是重新排序缓冲区。

假设使用商品硬件，节点之间的时钟差异是不可避免的。重新排序缓冲区除了测量节点之间的延迟外，还测量节点之间的差异。每个副本都可以使用此信息从每个节点正确排序数据并说明差异，从而通过时间戳协议保证一次往返共识。

另一种机制是快速通道选民。在恢复之前选择新的领导者时，故障模式会产生延迟。 Fast-path electorates 使用 Cassandra 中预先存在的功能和一些新颖的实现，以在 Cassandra 容忍的相同故障级别下保持无领导的快速路径到 quorum。可以在提案中阅读更多详细信息。

它是如何工作的？

最大的影响将是开发人员的生产力，所以让我们看看在实践中会是什么样子。考虑我们之前提到的以下银行账户转账示例：

首先是您将在 Cassandra 查询语言 (CQL) 中看到的新语法。事务包含在BEGIN TRANSACTION和COMMIT TRANSACTION声明中。事务标记内的所有内容都将独立于其他进程以原子方式发生。在这个例子中，我们将从 Alice 的账户中转 20 美元给 Bob。没有比这更经典的了！

在 A 部分，我们可以从现有记录中选择数据并将结果分配给元组（存储在单个变量中的多个项目）。根据SELECT子句中的列数，您可以在元组中存储一个或多个值。这些值将在 B 部分中用于在进行数据更改之前测试条件。

在这种情况下，我们将在转账给 Bob 之前测试 Alice 的账户中是否有 20 美元。如果是这样，则UPDATE将 Alice 的帐户余额减少 20 美元，然后将 Bob 的帐户余额增加 20 美元。如果爱丽丝的钱少于 20 美元，则不会发生更改。

从观察过程中可以看出，在幕后是一组独占执行的序列化数据库命令。跨一个或多个数据中心，交易只需要一次往返就可以达成共识，如果任何节点离线，如果至少有法定数量的副本可用，该操作仍会发生。

这正是 Cassandra 喜欢的工作方式，但我们只是通过全球可用的交易来提升我们的游戏。

下一步是什么

Accord 及其所有相关工作仍在进行中，预计将包含在下一个 Cassandra 版本中。由于这一切都是开源的，那些迫不及待的人可以从 Cassandra 存储库中克隆cep-15-accord分支的副本并构建您自己的副本。

对于其他人，随着发布时间的临近，我们将提供可供您使用和测试的版本。这将改变 Cassandra 的游戏规则，我相信您会想亲眼看看。

我最感兴趣的是听取社区的意见，了解以您期望从 Cassandra 获得的速度和弹性运行的全球可用事务会发现哪些用例。终于到了放弃那些最后的关系数据库工作负载的时候了吗？

我们也渴望听到您对我们所有渠道的反馈，包括 Apache Software Foundation Slack 或项目邮件列表。开源项目中的功能不断发展以满足用户的需求。这就是为什么您在塑造Apache Cassandra的未来方面发挥着关键作用。

敬请期待更多用例和信息，因为我们会发展这一激动人心的新功能。您可以预料，在 3 月 14 日举行的Cassandra Forward数字峰会上，将会有几次关于此的讨论。您不会想错过这些的。

作者：Patrick McFadin，DataStax

Patrick McFadin 是 O'Reilly 图书“在 Kubernetes 上管理云原生数据”的合著者。他目前在 DataStax 从事开发人员关系工作，并且是 Apache Cassandra 项目的贡献者。 Patrick 曾担任 Apache Cassandra 的首席布道师（他也是新成立的 Cassandra 提交者！），并担任 DataStax 的顾问，在那里他在生产中构建了一些最大的部署。