2.5PC：一个更快的非阻塞原子提交协议

2.5-PC: A Faster and Non-Blocking Atomic Commit Protocol

摘要：我们提出 2.5PC，一种非阻塞原子提交协议。2.5PC 是 3PC 的修改版，用于具有可靠网络通道的同步设置。2.5PC 等待与 2PC 相同数量的消息延迟，同时在非完全失败的情况下也是非阻塞的。我们提供了 2.5PC 正确性的非正式证明，并使用 Dafny 正式证明了 2.5PC 在正常运行期间的安全性。尽管 2.5PC 依赖于不切实际的网络设置，但 2.5PC 的证明改进了当前对非阻塞原子提交协议的理解。使用这种理解，我们展示了对 3PC 的实际改进，关于 3PC 第三阶段 ACK 消息的协调器超时延迟。此改进对使用空确认消息的其他协议具有实际意义。

关键词：原子承诺、两阶段提交、三阶段提交、非阻塞提交协议、TLA、霍尔逻辑验证

1 介绍

从一开始，原子承诺就一直是分布式系统中的主要问题。一些现实世界的系统依赖原子提交协议 （ACP） 来实现一致性 [1]–[4]。两个广泛使用的 ACP 是两阶段提交 （2PC） 和三阶段提交 （3PC） [5]。2PC 和 3PC 有很多版本，本文将重点介绍那些在同步消息通道假设下运行的版本。顾名思义，3PC 在正常执行期间需要一个额外的阶段才能终止。这个额外的阶段允许 3PC 是非阻塞的。也就是说，3PC 不会在非完全失败的情况下阻塞，而 2PC 的进程可能会在部分失败的情况下停滞。因此，我们将 3PC 称为非阻塞 ACP。尽管 3PC 是非阻塞的，但 2PC 在大多数实际系统中受到青睐，因为它少了一个阶段（即少了一个往返时间）。在本文中，我们讨论了为什么 3PC 需要一个额外的阶段才能成为非阻塞的。然后我们描述 2.5PC，一种新的 ACP，它是非阻塞的并且只需要 2 个阶段。

2.5PC 是依赖于可靠消息通道的 3PC 的修改。可靠信道的假设通常是不切实际的。尽管实际应用有限，但 2.5PC 的开发改进了当前对 3PC 为何是非阻塞的理解。利用这种理解，我们提出了一种适用于更实际网络设置的 3PC 的潜在优化。

2.5PC 是依赖于可靠消息通道的 3PC 的修改。可靠信道的假设通常是不切实际的。尽管实际应用有限，但 2.5PC 的开发改进了当前对 3PC 为何是非阻塞的理解。利用这种理解，我们提出了一种适用于更实际网络设置的 3PC 的潜在优化。

2 相关工作

IronFleet 表明，形式化机器验证在分布式系统的实际实现规模上是实用的 [7]。一个名为 TLA+ [8] 的较早但已建立的系统十多年来一直用于指定和验证分布式系统，包括亚马逊的 AWS 服务。IronFleet 对 TLA+ 进行了改进，使规范也可以充当实现并证明某些活性属性。mCRL2 是另一种规范语言，用于在不同网络条件下对 2PC 和 3PC 进行建模和验证 [6]。

3 原子承诺和 3PC 概述

本节简要介绍原子承诺和 3PC。考虑一个事务 T，它的执行依赖于几个分布式进程 S1、S2、…锡。只有每个进程都提交执行事务才能成功执行 T。如果 T 被某些进程提交，但被其他进程中止，则 T 将不一致地终止。需要一个原子提交协议 (ACP) 来确保 T 要么在每个进程中提交，要么在每个进程中中止，即使允许进程失败。具体来说，正确的 ACP 满足以下属性 [9]：

AC1：所有做出决定的过程都达到了同一个决定。
AC2：一个进程在达到一个之后不能改变它的决定。
AC3：只有在所有进程都投赞成票时才能做出 COMMIT 决定。
AC4：如果没有失败并且所有进程都投了赞成票，那么决定将提交。
AC5：如果所有的故障都被修复并且没有更多的故障，那么所有进程最终都会决定。

此外，如果操作流程始终可以通过检查其本地状态做出决定，即使其他流程失败，也可以认为 ACP 是非阻塞的。

3PC 满足 AC1-AC5 并且在存在部分故障时是非阻塞的。3PC 指定一个协调程序进程，负责监督其他参与进程的协议执行。3PC的执行过程如下：

1）协调者向每个参与者广播 VOTE-REQ；
2） 每个参与者都会收到一个 VOTE-REQ，并以 YES 票或 NO 票作为回应。如果参与者投反对票，它决定中止。
3） 如果协调器收到所有的赞成票，它广播PRE-COMMIT。如果协调器收到否决票，它会决定 ABORT 并广播 ABORT。
4） 每个参与者都会收到一个 PRE-COMMIT 或 ABORT。如果参与者收到 ABORT，它决定 ABORT 并终止。如果参与者收到 PRE-COMMIT，它会用 ACK 进行响应。
5）协调器收到ACK，决定COMMIT，并广播COMMIT。
6） 参与者收到 COMMIT 并决定 COMMIT。

4 为什么 3PC 是非阻塞的？

进程不确定期是指进程投赞成票之后，但在收到 PRE-COMMIT 或 ABORT 消息之前的时间段。在此期间，流程不确定会做出什么决定。 3PC 是非阻塞的，因为它满足以下非阻塞 NB 属性。

NB：如果一个操作流程处于其不确定期，则没有流程决定 COMMIT。

在步骤 5 中收到的 ACK 消息通知协调器每个进程都已退出其不确定期。收到这些消息后，协调器可以安全地决定 COMMIT。

这个版本的 3PC 在同步假设下运行。同步允许一个进程在一些超时延迟后确定另一个进程的死亡。在步骤 3 之后，协调器将超时设置为 2δ，其中 δ 是消息传递的上限。如果协调器未能在 2δ 时间内收到来自每个进程的 ACK 消息，则可以确定任何不确定的进程已经死亡并且可以在不违反 NB 的情况下安全地提交。

由于NB的性质，如果不确定进程发现协调器死亡，则不确定进程可以推理已死亡的协调员尚未决定 COMMIT;因此，不确定的进程不需要等待死亡的协调者恢复才能取得进展。

我们考虑一个较弱的非阻塞（WNB）：
WNB：如果一个进程已经决定 COMMIT，每个活着的不确定进程将在 θ 时间内退出它的不确定期。

我们将 θ 定义为确定另一个进程死亡所需时间的下限。在使用超时检测死亡的同步系统中，θ 取决于 δ，即消息传递的上限。

WNB 属性允许已提交的进程与活动的和不确定的进程共存；但是，如果一个活着的不确定进程得知另一个进程的死亡，那么这个活着的不确定进程就知道死进程还没有决定提交。如果 ACP 满足 WNB 属性，则存活和不确定的进程不需要等待死进程的恢复才能取得进展。

5 2.5 PC

我们提出 2.5 阶段提交 （2.5PC），这是一种满足 WNB 属性的非阻塞原子提交协议。我们修改3PC中的协调员，使其在发送PRE-COMMIT消息后立即发送COMMIT消息，从而省去了ACK消息，节省了1轮通信。2.5PC在同步和可靠信道的假设下运行。此外，一个进程只能通过超时获知另一个进程的死亡（也就是说，不使用 Falcon [10] 或类似的东西）。

2.5PC 遵循与 3PC 类似的结构，并采用其所有超时动作。2.5PC的执行如下：
1） 协调员向每个参与者广播 VOTE-REQ
2） 每个参与者都收到一个 VOTE-REQ，并以赞成票或反对票作为回应。如果参与者投反对票，它决定中止。
3）如果协调器收到所有的YES票，它广播PRE-COMMIT，决定COMMIT，然后广播COMMIT。如果协调器收到否决票，它会决定 ABORT 并向投 YES 的进程广播 ABORT。
4） 每个参与者都会收到一条 PRE-COMMIT、COMMIT 或 ABORT 消息。如果参与者收到 ABORT，它决定 ABORT 并终止。如果参与者收到PRE-COMMIT，它进入预提交状态并等待来自协调器的COMMIT消息。如果参与者收到 COMMIT，它决定 COMMIT 并终止。
5） 等待接收COMMIT消息的参与者收到COMMIT并决定COMMIT。

进程可能会在步骤 (2)、(3)、(4) 和 (5) 处超时。如果进程在步骤 （2） 中超时，则该进程可以独立决定 ABORT，因为还没有进程决定 COMMIT。如果协调器在步骤（3）中超时，它也可以独立决定ABORT并广播ABORT到投赞成票的进程。在步骤（4）和（5）中超时的进程不能独立决定。相反，一个新的协调器被选举出来，并且进程参与了[9]中描述的 3PC 的终止协议。此终止协议满足 NB 属性，因此满足 WNB 属性。

如果协调器在步骤 （3） 中收到所有 YES 票，如果它无论如何都要发送 COMMIT，为什么还要发送 PRE-COMMIT？ PRE-COMMIT 消息的目的是确保维护 WNB 属性。在向协调器发送投票后，进程设置 3δ 的超时并期​​望在该时间内收到来自协调器的消息。它选择 3δ 是因为在发送投票时可能仍有一个 VOTE-REQ 消息正在运行。每个 VOTE-REQ 最多可以花费 δ 时间到达。每个后续的投票消息将最多花费 δ 时间。最终的决定最多需要 δ 时间，因此，3δ。当最终的 YES 投票在步骤 (3) 中到达时，协调器可以推断出最早设置超时的进程是在 2δ 时间之前。从协调器的角度来看，任何进程超时的下限是剩余的 δ 时间。由于我们对可靠通道的假设，协调器可以通过向每个进程发送 PRE-COMMIT 消息来保证每个活动的和不确定的进程将在 δ 时间内退出其不确定期。在向每个进程发送 PRE-COMMIT 之后，协调器广播 COMMIT。当进程在步骤 （4） 或 （5） 中收到 COMMIT 消息时，它可以推断每个活动的和不确定的进程都有一个正在运行的 PRE-COMMIT 消息。也就是说，如果协调器在广播COMMIT 时死亡，则每个不确定进程都会在得知协调器死亡之前退出其不确定期。因此，接收到 COMMIT 消息的进程可以在不违反 WNB 属性的情况下安全地提交。

6 2.5 PC 的非正式证明

在本节中，我们概述了 2.5PC 正确性的非正式证明，该证明利用了 WNB 和 NB 属性之间的功能等价性。NB 属性比 WNB 属性更强大，因为 NB 属性不允许已提交进程与活动进程和不确定进程共存。

由于 2.5PC 借鉴了 3PC 的大部分协议，因此其正确性取决于 3PC 的正确性。3PC 和 2.5PC 仅在一个进程不确定而另一个进程已决定 COMMIT 的情况下有所不同。所有其他可能的状态都包含在旧的非阻塞属性和 3PC 的正确性中。具体来说，如果任何进程决定COMMIT，我们必须确保任何不确定的进程永远不会决定ABORT，最终会决定COMMIT。

引理 1.如果协调者在步骤 （4） 中决定 COMMIT，则没有参与者会决定 ABORT，并且每个操作过程最终都会决定 COMMIT。

证明。在协调器没有死掉的情况下，那么协调器会向每个进程发送COMMIT消息。

从我们的网络假设来看，每个活着的进程都会收到 COMMIT 消息并决定 COMMIT。由于协调器已决定 COMMIT，因此它已收到来自每个进程的 YES 票。因此，没有进程决定 ABORT，并且协调器不发送 ABORT 消息。

在协调器失败的情况下，因为它已经决定提交，所以它已经向每个进程发送了一个 PRE-COMMIT 消息。根据我们的网络假设，每个进程将在 δ 时间内收到一条 PRE-COMMIT 消息。当协调器发送 PRE-COMMIT 时，进程在协调器上超时的最早时间也是 δ。每个没有收到COMMIT消息的进程只有在收到PRE-COMMIT消息后才会在协调器上超时，进入PRE-COMMITTED状态的3PC终止协议。从终止协议的正确性来看，每个进程最终都会决定COMMIT。

引理 2. 如果任何人已经决定 COMMIT，每个死的不确定进程在恢复后不会决定 ABORT

证明。当一个不确定的过程恢复时，有两种情况需要解决。

第一种情况是非完全失败。根据引理 1，存在一个活动进程，它最终可以通知恢复进程 COMMIT 决定。

第二种情况是彻底失败。从WNB属性来看，当一个不确定的进程死亡时，它还没有得知一个已经决定COMMIT的进程死亡。也就是说，不确定进程在其 UP-Set 中保留任何可能决定 COMMIT 的进程。当这样一个不确定的进程恢复时，它要么从已经恢复的进程中获悉 COMMIT 决策，要么阻塞直到其 UP-Set 中的已提交进程恢复。

7 确认信息

在本节中，我们对 3PC 提出了一个小的优化，即使存在不可靠的信道也能正常工作。3PC 的一个微妙方面是在步骤 （5） 期间——当协调器正在等待 ACK 时——协调器将执行相同的操作，无论它是否收到所有 ACK 或超时。这是因为超时或收到 ACK 可确保同一件事——协调器可以安全地决定 COMMIT，因为进程已经退出其不确定期或崩溃。

在探讨为什么存在 ACK 消息之前，重要的是要了解如何在不可靠的信道上保证同步。在存在不可靠通道的情况下，进程会多次重新发送消息，以确保（以极高的概率）至少有一条消息将在 δ 时间内传送。这就是 TCP 保证可靠数据包传送的方式。在 3PC 中，协调器在发送 PRE-COMMIT 消息后设置 2δ 的超时。如果 alive 协调器在 2δ 后等待 ACK 消息超时，则可以确定它超时的进程已经崩溃。重要的是协调器还活着以进行此推理，因为它需要存活足够长的时间才能不断重新发送其消息。如果一个活着的协调器等待 2δ 时间，它可以安全地推断它发送的消息已经可靠地传递，或者接收进程已经死亡。如果一个活着的协调器只等待一次 δ 时间，它也可以安全地推断它发送的消息已经可靠地传递，或者接收进程已经死亡并丢弃了消息。在任何一种情况下，在 δ 时间之后，协调器在不违反 NB 属性的情况下决定 COMMIT 都是安全的。这正是我们提出的优化，协调器在决定 COMMIT 之前不需要等待 2δ。

那么为什么3PC中会有ACK消息呢？协调器可以在发送 PRE-COMMIT 后简单地等待 δ 时间，而不期望返回 ACK 消息。ACK 消息很可能会在 δ 时间过去之前到达，因此发送 ACK 消息可能比让协调器始终等待完整的 δ 时间更快。

8 2.5 PC 机器证明

我们使用支持形式规范 1 的编程语言 Dafny 归纳证明 2.5PC 的安全性。我们将 2.5PC 的全局状态建模为一系列节点（参与者进程）和它们之间发送的消息。我们还将全局状态可以作为原子协议步骤进行的每个状态转换建模。为简单起见，我们只允许一个进程在全局状态转换期间更新其状态。这是采取的方法由 IronFleet [7] 证明，可以证明等同于真实系统的证明。图 3 显示了系统的全局状态是如何在 Dafny 中建模的。图 4 显示了单个进程的一种可能的状态转换。

图 3.初始状态谓词。环境变量模拟同步网络环境。服务器变量包含一组参与进程。第 4 行表示环境处于有效的初始状态（没有发送消息等）。第 5 行表示每个参与进程都处于有效的初始状态（进程尚未决定等）。

图 4.节点死亡转换谓词。prev 表示一个Node（一个参与进程）之前的状态，next 是该节点转移后的状态。第 3 行确保在转换期间仅更改 is_alive 属性。

图 5.安全特性：在 Dafny 中建模的 ACP 的安全特性。AC2 比较多个状态，其中 state’ 在 state 之后。

图 6.简单证明。证明初始状态不违反 AC1、AC2 或 AC3。请注意，对于任何状态快照，AC2 都是微不足道的。

图 7.2.5PC 的证明。Inv 谓词封装了每个归纳不变量。首先我们证明 Inv → （AC1 && AC3）。然后我们证明初始状态满足 Inv。最后，我们表明从满足 Inv 的状态的任何转换也满足 Inv 和 AC2。

通过定义我们协议的初始全局状态和每个可能的状态转换，我们已经合理地定义了 2.5PC 的操作（以归纳方式）而无需实现它。

我们通过第一个表达式归纳证明 2.5PC 的正确性在 Dafny 中使用原子提交 （AC） 安全属性。实现这些安全属性后，我们可以开始编写简单的证明，例如图 7 中的证明。为了证明归纳步骤，我们证明给定一个安全状态，从该状态的任何有效转换也是安全的。证明归纳步骤的难点在于，所有满足 AC1-AC3 的状态都可能无法从初始状态到达。我们定义了一系列归纳不变量来删除可能导致不安全状态的无法到达的安全状态。一个这样的不变量是，如果有一个进程决定 ABORT，则 COMMIT 消息不能在飞行中。我们还必须证明我们的初始状态也满足每个归纳不变量。我们证明的完整抽象如图 7 所示。

在本文发表时，我们已经正式验证了2.5PC在没有终止协议的情况下正常运行的正确性。我们了解到 Dafny 程序很难调试，验证通常需要很长时间才能运行;然而，当终端显示“Dafny 程序验证器已完成 87 个验证，0 个错误”时，我感到非常满意。

我们提出了 2.5PC，这是一种新的原子提交协议，它在同步和可靠通道的假设下运行。2.5PC 能够在正常操作期间仅在两个阶段的消息中完成，同时在存在非完全故障的情况下也是非阻塞的。我们使用 TLA 的组合正式证明 2.5PC 在正常情况下的安全性和霍尔逻辑验证。我们的证明是用 Dafny 编写的，Dafny 是一种支持形式验证的编程语言。

未来的工作：我们已将终止协议安全性的机器证明留给未来的工作。

参考

[1] J. C. Corbett, J. Dean, M. Epstein, A. Fikes, C. Frost, J. J. Furman, S. Ghemawat, A. Gubarev, C. Heiser, P. Hochschild, W. Hsieh, S. Kanthak, E. Kogan, H. Li, A. Lloyd, S. Melnik, D. Mwaura, D. Nagle, S. Quinlan, R. Rao, L. Rolig, Y. Saito, M. Szymaniak, C. Taylor, R. Wang, and D. Woodford, “Spanner: Google’s globally distributed database,” ACM Trans. Comput. Syst., vol. 31, no. 3, pp. 8:1–8:22, Aug. 2013. [Online]. Available: http://doi.acm.org/10.1145/2491245
[2] T. B. Schardl, W. S. Moses, and C. E. Leiserson, “Tapir: Embedding fork-join parallelism into llvm’s intermediate representation,” inProceedings of the 22Nd ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, ser. PPoPP '17. New York, NY, USA: ACM, 2017, pp. 249–265. [Online]. Available: http://doi.acm.org/10.1145/3018743.3018758
[3] M. K. Aguilera, A. Merchant, M. Shah, A. Veitch, and C. Karamanolis, "Sinfonia: A new paradigm for building scalable distributed systems,"SIGOPS Oper. Syst. Rev., vol. 41, no. 6, pp. 159–174, Oct. 2007. [Online]. Available: http://doi.acm.org/10.1145/1323293.1294278
[4] J. Baker, C. Bond, J. C. Corbett, J. Furman, A. Khorlin, J. Larson, J.-M. Leon, Y. Li, A. Lloyd, and V. Yushprakh, “Megastore: Providing scalable, highly available storage for interactive services,” 2011.
[5] D. Skeen, “A quorum-based commit protocol,” Ithaca, NY, USA, Tech. Rep., 1982.
[6] M. Atif, “Analysis and verification of two-phase commit three-phase commit protocols,” in 2009 International Conference on Emerging Technologies, Oct 2009, pp. 326–331.
[7] C. Hawblitzel, J. Howell, M. Kapritsos, J. Lorch, B. Parno, L. Stephenson, S. Setty, and B. Zill, “Ironfleet: Proving practical distributed systems correct,” in Proceedings of the ACM Symposium on Operating Systems Principles (SOSP), October 2015.
[8] L. Lamport, Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002.
[9] P. A. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency Control and Recovery in Database Systems. Boston, MA, USA: AddisonWesley Longman Publishing Co., Inc., 1986.
[10] J. B. Leners, H. Wu, W.-L. Hung, M. K. Aguilera, and M. Walfish, “Detecting failures in distributed systems with the falcon spy network,” in Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles, ser. SOSP '11. New York, NY, USA: ACM, 2011, pp. 279–294. [Online]. Available: http://doi.acm.org/10.1145/2043556.2043583