事務提交上的共識

有點難啃的一篇paper，讀這篇paper需要對Paxos共識算法有一定的熟悉程度。

為什么需要對事務的提交要達成共識

這里的共識指的是對于一個決議選定的值達成多數(shù)派的同意。

為什么需要這個共識？因為在傳統(tǒng)的事務兩階段提交里，協(xié)調者的身份是作為事務的發(fā)起者和提交者，事務能否提交或者事務已經(jīng)提交完全取決于協(xié)調者自身收到的信息和記錄的信息。

相當于，協(xié)調者是一個中心節(jié)點，如果協(xié)調者出現(xiàn)故障，那么后續(xù)的事務不能開啟，正在執(zhí)行的事務狀態(tài)不明。

或許你會說，我多搞幾個協(xié)調者節(jié)點就行了，這個也只能解決一部分問題，即后續(xù)的事務可以開啟了。但是前一個節(jié)點那些未決的事務實際上還在那里卡著。

問題出現(xiàn)在了，決定事務提交和回滾的這幾條決議，是由一個節(jié)點來負責的，也就是協(xié)調者。而不是由一組節(jié)點共同達成共識來決定的。這就間接導致了單個做決議，跪了就全跪了，多個節(jié)點一起做決議，跪了一個還能有其它的節(jié)點頂上來。這樣只要做過的決議，還能讀取出來，繼續(xù)向前處理。其實思路就是這個，多少個節(jié)點一起做決議呢？2F+1個，不過實際操作的時候，只給F+1個發(fā)送消息要求其做決議。如果這F+1個有幾個連不通，再在剩下的里面選幾個發(fā)。

簡單的對比：
paxos commit相當于把原來的1個協(xié)調者做決議，擴充到了2F+1個協(xié)調者做決議。

經(jīng)過計算，Paxos Commit和經(jīng)典的兩階段提交，具有相同的持久化延遲和消息發(fā)送延遲（前提是在無錯的情況）。但Paxos Commit的消息數(shù)量會更多。傳統(tǒng)的兩階段提交算法是Paxos Commit算法的一個特例，即F=0的時候的特例。

介紹

通常情況下，一個算法需要對兩種正確性的特性滿足：

1. 安全性（Safety）：描述什么是允許發(fā)生的，什么是絕對不能發(fā)生的。
2. 活性（Liveness）：描述什么是必須要發(fā)生的。

事務提交

在分布式系統(tǒng)中，事務是被一組叫做的Resource Manageers（RMs）的進程執(zhí)行的，每個執(zhí)行都發(fā)生在不同的節(jié)點上。

事務的提交意味著每個參與事務的RM必須愿意提交它，要不然事務必須被終止。

最基礎的要求是：所有的RMs必須最終在事務提交和終止上達成一致。

我們抽象出事務提交協(xié)議如下，每個進程開始從一個working狀態(tài)。所有的RMs必須最終達到committed狀態(tài)或者aborted狀態(tài)。

兩個安全性需要如下：

• Stability：一旦一個RM已經(jīng)進入到committed 或者 aborted狀態(tài)，它將永遠保持在這個狀態(tài)。
• Consistency：不可能存在一個RM已經(jīng)是在committed狀態(tài)，但是其它RMs卻在abort狀態(tài)。

每個RM還有一個prepared狀態(tài)，即：

一個RM可以進入committed狀態(tài)只有在所有的RMs已經(jīng)處于prepared狀態(tài)的時候。

所有的RMs到達committed的狀態(tài)只能按照如下事件發(fā)生：

1. 所有的RMs進入到prepared狀態(tài)，以任何的順序
2. 所有的RMs進入到committed狀態(tài)，以任何順序

協(xié)議允許如下的事件來終止這個事務提交：

任意一個RM從working狀態(tài)可以進入到終止狀態(tài)。但不允許出現(xiàn)已經(jīng)有一個RM進入到committed狀態(tài)，該RM還繼續(xù)終止事務。

2pc state

我們對于事務提交的協(xié)議有兩個關于Liveness的要求：

• Non-Triviality（非平凡條件，有實際效果的，在一定條件下做出有效決策）: 如果在貫穿整個事務執(zhí)行的過程中網(wǎng)絡是沒有錯誤的。則
  1. 如果所有的RMs到達prepared 狀態(tài)，之后所有的RMs最終到達committed狀態(tài)。
  2. 如果一些RM到達了aborted 狀態(tài)，那么所有的RMs最終到達aborted狀態(tài)。
• Non-Blocking: 如果，在任意時間，足夠多的節(jié)點所在的網(wǎng)絡能夠維持足夠長的時間沒有錯誤，那么每個在這些節(jié)點上執(zhí)行的RM將最終達到committed 或者aborted狀態(tài)。

可以更精確的描述事務提交協(xié)議，通過描述其一系列的合理行為，這些行為是在一系列的狀態(tài)下來執(zhí)行的。假設所有的RMs是在working state。為了定義下一個狀態(tài)的關聯(lián)，我們定義兩個狀態(tài)的預測：

• canCommit: 為True當且僅當所有的RMs處于prepared或者committed狀態(tài)。
• notCommitted: 為True當且僅當沒有RM處于committed狀態(tài)。

每個單獨的RM根據(jù)狀態(tài)的預測，每個狀態(tài)下可以由如下的兩個行為組成：

• Prepare: RM可以轉換working狀態(tài)到prepared狀態(tài)。
• Decide: 如果RM處于prepared狀態(tài)，而且canCommit是true，則其可以轉換自己的狀態(tài)到committed狀態(tài)；如果RM是在working或者prepared狀態(tài)，并且notCommit是true，則其可以轉換自己的狀態(tài)為aborted狀態(tài)。

兩階段提交在無錯誤情況下的流程簡略圖示：

2pc

兩階段提交的代價

• 一個RM進入Prepared狀態(tài)，并且發(fā)送 一個Prepared消息給TM。（1 條消息）
• TM發(fā)送Prepare消息給其它所有RMs。（N-1條消息）
• 其它所有RM發(fā)送Prepared消息給TM。（N-1條消息）
• TM發(fā)送Commit消息給所有的RM。（N條消息）

所以，總共的消息數(shù)量 3N - 1。一般情況下，TM和RM會在同一個節(jié)點上，這種情況下，兩條消息（TM->RMd的Prepared和RM->TM的Response）可以省略，最終3N - 3條消息發(fā)送。并且有3次消息的延遲。

對于持久化的代價如下：

1. 第一個RM寫入Prepared狀態(tài)到磁盤上。
2. 剩下的RM進入Prepared，寫Prepared狀態(tài)到磁盤上。
3. TM在收到所有的RMs的Prepared之后，做出Commit決定，記錄磁盤。

所以共有3次寫入磁盤等待。

兩階段提交的問題

TM失敗會引起協(xié)議阻塞，直到TM恢復了。尤其是如果TM剛好在每個RM都發(fā)送Prepared回復之后掛了，那么所有其它的的RMs沒辦法知道TM是Committed還是aborted這個事務。

一個非阻塞的提交協(xié)議即單個的進程的失敗不會阻止其它進程去決定事務提交或者中斷。這類協(xié)議通常成為 三階段提交協(xié)議。（不過Lamport在這里說沒有誰給出一個完整的證明，來解釋一個進程在收到兩個不同的TM進程發(fā)來的消息的時候該怎么做）。

Paxos Commit

Paxos Commit使用一個單獨的Paxos共識算法實例來在讓RM去達到prepare或者abort上達成共識。共識選定的值即為：Prepared和Aborted。所以，每個RM均會有一個paxos共識實例。
事務提交了當且僅當每個RM的實例均選擇了Prepared。要不然事務就是Aborted。
Paxos Commit使用2F+1個acceptors和一個當前的Leader來執(zhí)行每個paxos實例。所以這里角色有：

• N RMs
• 2F+1 Acceptors
• 1 current leader。
  我們假設RMs事先是知道所有的Acceptors的。在Paxos中，一個ballot 0的phase 2a是可以攜帶任何value的。

Paxos Commit的大致執(zhí)行過程如下：

1. 一些RM決定要prepare，于是發(fā)送BeginCommit給Leader。
2. Leader發(fā)送一個Prepare消息給其它所有參與的RMs。
3. 如果RM也決定要prepare，它會開啟一次paxos instance，使用ballot 0的phase 2a消息，并攜帶value為Prepared。要不然（不準備prepare）就攜帶Aborted。
4. Acceptors收到2a消息后，將要回復的2b消息回復給Leader（每個RM的instance，Leader均需要收夠2F+1個才能知道Acceptors對提案已經(jīng)形成多數(shù)派決議了），Leader就知道了是否所有的RMs均已經(jīng)對事務形成Prepared決議。
5. Leader知道了所有Acceptors的結果之后，給每個RM發(fā)送下一步Commit或者Abort，事務可以被提交當且僅當每個RM的instance的決議均為Prepared，要不然事務就是要被終止的。
   （這里Leader接收結果可換成直接讓RMs接收2b的結果，省去了一次消息延遲）

如果Leader等待某個RM的2b沒有等到（通過超時機制），則表示一個或多個RM的prepare決議可能沒有達成共識。Leader會在這個instance上使用一個更大的ballot num區(qū)檢測是否真的沒有達成決議。如果在2a時，Leader收到的決議可以是任意值時（意味著確實沒有達成共識），此時Leader會促使其達成abort共識，將其成為決議，通過在2b中攜帶value Aborted。

這里存在一個優(yōu)化，就是如果Leader在收取所在RMs的instance的2b時，一旦收到其中一個instance的決議是Aborted，則可以快速讓整個事務失敗。通過短路機制，即可以用什么廣播協(xié)議通知所有參與事務的進程，事務已經(jīng)被Aborted了，一旦一個進程知道事務被Aborted，它可以忽略其它協(xié)議的消息）。

我們看看Paxos提交算法是否滿足了之前非阻塞算法應該滿足的四個特性，即：

• Stability: 一旦RM收到來自Leader的決議，它就不會修改決議。穩(wěn)定性有保障。
• Consistency: 一致性是由Paxos算法來保證的，即一個instance中只能 選定一個值。
• Non-Triviality: 如果Leader在使用新的bllot num（應該是大于0的ballot num）執(zhí)行phase 1a前等待足夠長的時間，所以，如果沒有出現(xiàn)失敗的情況，每個Paxos實例應該在用ballot 0執(zhí)行phase 2a時就執(zhí)行完了。（表示Leader會主動做動作的，或者Acceptors沒有失敗就不需要Leader主動處理）
• Non-Blocking: 通過Paxos的progress特性來滿足的，即如果存在一個足夠大的于Acceptors節(jié)點間的網(wǎng)絡，是沒有錯誤的，則每個Paxos實例將最終選定要么Prepared或者Aborted。

在沒有錯誤的情況下，Paxos Commit的提交過程。

paxos 2pc

Paxos Commit的代價

消息數(shù)量

假設有N個RMs，假設系統(tǒng)能容忍F個失敗，所以需要有2F+1個Acceptors。我們在這里優(yōu)化一下，Leader只給F+1個Acceptor發(fā)送消息，當有發(fā)不過去或者回不來的Acceptor存在時，再換一個發(fā)。則Paxos 提交算法會有潛在的節(jié)點間通信數(shù)量如下：

1. 第一個RM要prepare，發(fā)送一個BeginCommit消息給到Leader。（1條消息）
2. Leader發(fā)送一個Prepare消息給所有其它的RMs（N-1條消息）
3. 每個RM發(fā)送一個bollot 0 phase 2a 帶Prepared value的instance消息給F+1個Acceptors（N（F+1）條消息）
4. 對于每個RM的Paxos instance來說，Acceptor回復2a的2b消息給Leader，但是可以讓每個Acceptor都等到收到所有RMs的instanc的2a之后再一并回復給Leader，即將其綁定到一條消息里面。（F+1 條消息）
5. Leader給所有的RMs發(fā)送Commit消息并攜帶了每個instance的phase 3 Prepared的消息。（N 條消息）

持久化磁盤數(shù)量

Paxos Commit和傳統(tǒng)的兩階段提交有著相同的寫延遲。

1. 當RM要進入到prepared狀態(tài)時，RM記錄消息到持久化設備上。 N條記錄
2. Acceptors在回復2b決議的時候，要先記錄到自己的持久化設備上。F+1條記錄

一些優(yōu)化：

1. initial leader和其中一個Acceptor是在同一個節(jié)點上的，則一個2b Prepared消息可以被優(yōu)化。更進一步第一個RM的BeginCommit可以和2a 一起發(fā)，又省一條。
2. 如果 N >= F，并且每個Acceptor均和RM在同一節(jié)點部署，并且第一個RM和Leader在同一個節(jié)點上。則第一個RM到Leader的消息可以省了，并且F個2a的消息變成了節(jié)點內(nèi)部的。
3. 我們可以讓phase 3 消息不用Leader發(fā)，而是讓Acceptors直接發(fā)送給每個RMs。這就要求RM能夠歸并Acceptors的結果，并從中學習到結果。這樣會減少一次消息傳送的延遲。但造成了更多的消息發(fā)送，即N(2F+3)，不過加上2中的優(yōu)化，可以讓消息總量在(N-1)(2F+3)條。消息延遲成了3個。
4. 如果能夠讓RMs都自發(fā)地發(fā)起Prepare，而不用Leader間接去通知，則消息延遲降低成2個。

cost

這里的co-locatin表示混合部署。

詳細的推導過程不贅述了，參見原論文。

傳統(tǒng)的兩階段提交相當于是 F=0 時的Paxos Commit的特例退化。

簡單總結一下

實際上Paxos Commit是消除了（弱化了）TM一個進程的決策。因為傳統(tǒng)的2PC中TM可以單方面決定是否提交或Abort。也就是通過弱化TM，去中心化來使得決議本身成為可靠的結果。即：

1. 代替單個TM的持久化存儲為多個Acceptors的持久化存儲。
2. 代替單個TM為一組可能的Leaders集合。

Paxos Commit更進一步地從本質上消除了TM的決策的角色。

Paxos Commit在具體實現(xiàn)上

事務的創(chuàng)建、注冊、加入、提交、獲取結果

（這里與上面最大的不同點就是多了一次共識，即registrar要將參與者RMs的列表先達到共識，相當于持久化下來，之后才是給其它RM發(fā)送Prepare，讓RMs自己開始自己的paxos instance）

以下是ChatGPT3.5的一些相關問答：
這里直接使用ChatGPT 3.5的結果

在Consensus on Transaction Commit論文中，一個Paxos Commit事務最終的執(zhí)行流程是怎樣的？每個參與的進程及其作用分別是什么？
ChatGPT 說：
ChatGPT
在 Consensus on Transaction Commit 論文中，Paxos Commit 提出了基于 Paxos 共識協(xié)議的事務提交機制，旨在解決傳統(tǒng) Two-Phase Commit (2PC) 的單點故障問題。以下是 Paxos Commit 中事務最終執(zhí)行流程的簡要概述，以及每個參與進程的角色及其作用。

Paxos Commit 執(zhí)行流程
Paxos Commit 的執(zhí)行流程基于 Paxos 協(xié)議，用于保證分布式系統(tǒng)中的一致性決策。以下是事務執(zhí)行的主要步驟：

事務初始化階段：

Initial Leader (通常為 TM 或 RM)：負責發(fā)起 Paxos 提案來決定事務的提交或回滾。初始 Leader 會先向其他參與者提議一個事務決策過程，類似于傳統(tǒng) 2PC 的 prepare 階段。（筆者注：初始Leader是在事務注冊之后，記錄的當時的Leader。）
Resource Managers (RMs)：代表資源的持有者，例如數(shù)據(jù)庫節(jié)點。RMs 接收 Initial Leader 發(fā)起的提案請求，進行處理，并回應是否接受該提案。
Registrar：登記事務相關的元數(shù)據(jù)，主要是用來跟蹤事務的參與者（RMs）。Registrar 并不參與事務決策過程，而是作為一個元數(shù)據(jù)服務，為查詢事務狀態(tài)或恢復操作提供支持。
Prepare 階段：

Initial Leader：Initial Leader 向所有的 RMs 發(fā)送 Prepare 消息，詢問它們是否愿意提交事務。此時，Leader 開始發(fā)起提案。
RMs：RMs 收到 Prepare 消息后，檢查其本地狀態(tài)，決定是否準備提交。如果愿意提交，它們會向 Leader 發(fā)送 "Prepared" 的響應，表示它們已準備好提交。
Paxos 執(zhí)行階段（Propose 階段）：

Initial Leader：收集足夠多的“Prepared”響應后，Initial Leader 發(fā)起一個正式的 Paxos 提案，決定事務是提交還是回滾。這時，Leader 開始推進共識決策。
Paxos Acceptors：所有參與的進程（可能包括 RMs）作為 Paxos 協(xié)議的 Acceptor，接收并表決是否接受該提案。如果大多數(shù)（quorum）的 Acceptor 接受該提案，則提案被認為達成一致。
決策執(zhí)行階段：

Initial Leader：在收到足夠多的 Acceptor 同意提案的回應后，Leader 宣布最終決定（commit 或 abort）。該決定會被廣播給所有的 RMs。
RMs：RMs 根據(jù)最終的決策執(zhí)行提交或回滾操作，并記錄該事務的最終狀態(tài)。
事務完成階段：

Initial Leader 和 RMs：一旦所有 RMs 執(zhí)行了決策，事務完成。RMs 可能會記錄最終狀態(tài)以應對潛在的故障恢復情況。
參與進程及其作用
Initial Leader (通常為 TM 或 RM)：

發(fā)起并領導整個事務提交流程。
負責提案生成和推進 Paxos 共識協(xié)議。
在事務過程中，充當協(xié)調者角色，但與傳統(tǒng) 2PC 的 TM 不同，Paxos Commit 中 Leader 可容錯，并可在故障時切換。
Resource Managers (RMs)：

資源持有者，負責檢查其本地資源狀態(tài)，決定是否參與事務提交。
作為 Paxos 的 Acceptor，參與提案的表決并執(zhí)行最終的事務決策。
在事務執(zhí)行中，負責實際的資源提交或回滾操作。
Paxos Acceptors：

參與 Paxos 協(xié)議的節(jié)點，負責表決提案并達成一致。
一些 RMs 也可以充當 Acceptor 角色，但并不是所有參與者都必須是 Acceptor。
Registrar：

登記事務的參與者和元數(shù)據(jù)。
并不直接參與決策過程，但在故障恢復時，Registrar 的記錄可用于查找事務的參與者和狀態(tài)。
總結
Paxos Commit 的事務執(zhí)行流程基于 Paxos 協(xié)議，通過選舉 Leader 發(fā)起事務提案，并通過 Paxos 多數(shù)派決策機制達成一致，從而避免了傳統(tǒng) 2PC 中協(xié)調者單點故障的問題。每個進程都有明確的角色，負責不同的任務，確保在部分進程故障的情況下，系統(tǒng)仍然能夠繼續(xù)進行決策并完成事務。

您說：
在上文中initial leader和leader的區(qū)別是什么？
ChatGPT 說：
ChatGPT
在 Paxos Commit 的上下文中，Initial Leader 和 Leader 實際上是相關但不同的概念，它們的區(qū)別主要體現(xiàn)在以下幾個方面：

1.  Initial Leader:
    角色定義: Initial Leader 是指在 Paxos Commit 流程啟動時，首先被選中的那個發(fā)起者或協(xié)調者。這個角色通常會由一個 Resource Manager (RM) 或事務管理器（TM）扮演，負責開始事務提交的提案流程。
    任務: Initial Leader 負責向其他參與者發(fā)送初始的提案消息（Prepare 階段）并收集響應。如果 Initial Leader 成功引導整個過程，那么它將繼續(xù)擔任 Leader 角色，直到事務完成。
    容錯性: 如果 Initial Leader 失敗或掛掉，其他參與者可以通過 Paxos 協(xié)議重新選舉一個新的 Leader。Initial Leader 僅僅是初始發(fā)起者，但并不保證始終是后續(xù)流程中的 Leader。
2.  Leader:
    角色定義: Leader 是在 Paxos 協(xié)議執(zhí)行過程中實際領導提案的那個節(jié)點。它負責推動提案，并與其他參與者（Acceptor）進行通信，直至達成共識。在整個事務決策過程中，可能會出現(xiàn)多個不同的 Leader，因為 Paxos 允許在故障或競爭的情況下進行重新選舉。
    任務: Leader 的任務是發(fā)起和推進 Paxos 協(xié)議中的提案。Leader 發(fā)出的提案需要得到多數(shù)派參與者的接受（quorum）才能達成共識。
    動態(tài)變化: Leader 可以動態(tài)變化。如果當前 Leader 失敗或沒有得到足夠的響應，其他節(jié)點可以通過 Paxos 機制成為新的 Leader，并繼續(xù)推進提案。Leader 的職責在整個協(xié)議執(zhí)行期間可能會轉移。
    兩者的關系:
    Initial Leader 是整個 Paxos Commit 流程的第一個提案發(fā)起者，通常由某個進程預先擔任。這個角色是靜態(tài)分配的，并且負責啟動事務的準備階段。
    Leader 是在 Paxos 協(xié)議執(zhí)行過程中的實際決策領導者。雖然 Initial Leader 在流程啟動時通常會擔任 Leader 角色，但在協(xié)議執(zhí)行過程中，Leader 可以發(fā)生變化。例如，如果 Initial Leader 失效或遇到問題，Paxos 機制將允許其他進程成為新的 Leader。
    總結
    Initial Leader 是啟動事務的第一個協(xié)調者，負責開始提案流程。
    Leader 是在 Paxos 協(xié)議執(zhí)行過程中，實際推動共識達成的節(jié)點。Initial Leader 通常最先擔任 Leader，但在故障或其他情況下，Leader 角色可以動態(tài)變化。
    兩者的關鍵區(qū)別在于角色的時間點和持續(xù)性：Initial Leader 是啟動階段的角色，而 Leader 是在整個協(xié)議過程中領導提案的角色，并且可能會隨時間發(fā)生變化。

4/4

您說：
在Consensus on Transaction Commit 論文中，the names of the transaction's coordinator processes 具體指的是什么？這些進程的功能是什么？
ChatGPT 說：
ChatGPT
在 Consensus on Transaction Commit 論文中，提到的“the names of the transaction's coordinator processes” 指的是在 Paxos Commit 協(xié)議中與事務協(xié)調相關的進程名稱或角色。為了更好地理解這些進程的功能，我們需要知道它們在事務提交過程中的作用。

事務協(xié)調進程的名稱和功能
在 Paxos Commit 協(xié)議中，主要涉及以下幾類進程：

Initial Leader (或 Initial Coordinator)：

功能: 負責啟動事務的提交流程。Initial Leader 發(fā)起事務提交提案，向所有參與者（通常是 Resource Managers, RMs）發(fā)送 Prepare 消息。它在事務開始時起著關鍵的領導作用。
角色: 在事務開始時，Initial Leader 是事務協(xié)調的發(fā)起者，負責開始提案過程。
Paxos Leader：

功能: 在事務提交過程的執(zhí)行階段，Paxos Leader 負責提出提案并推動共識過程。Leader 通過 Paxos 協(xié)議與其他參與者溝通，以達成關于事務提交或回滾的最終決定。
角色: Paxos Leader 可能是 Initial Leader 也可能是后續(xù)通過 Paxos 選舉出來的 Leader。它負責發(fā)起和推進提案，確保事務最終達成一致。
Paxos Acceptors：

功能: 參與 Paxos 協(xié)議的進程，負責接收和表決事務提交的提案。Acceptors 對提案進行投票，決定是否接受事務提交。
角色: Acceptors 是參與決策的節(jié)點，通過接受提案來幫助達成共識。Paxos 協(xié)議要求多數(shù)（quorum）的 Acceptors 接受提案才能完成決策。
Resource Managers (RMs)：

功能: 代表實際資源的持有者，例如數(shù)據(jù)庫節(jié)點。它們接收事務的提交請求，執(zhí)行實際的事務操作（如提交或回滾），并在 Paxos 協(xié)議中充當 Acceptors 的角色。
角色: RMs 執(zhí)行事務的實際操作，并且在 Paxos 協(xié)議中參與投票，最終決定事務的提交或回滾。
Registrar：

功能: 記錄事務的相關元數(shù)據(jù)，跟蹤事務的參與者和狀態(tài)。雖然 Registrar 不直接參與事務的決策，但它負責維護事務的登記信息。
角色: Registrar 提供事務狀態(tài)的查詢服務，并在事務恢復或故障處理過程中提供支持。
總結
在 Consensus on Transaction Commit 論文中，"the names of the transaction's coordinator processes" 涵蓋了這些關鍵的進程角色：

Initial Leader：事務提案的發(fā)起者，啟動事務提交流程。
Paxos Leader：負責推動 Paxos 協(xié)議和達成最終的事務決策。
Paxos Acceptors：參與投票和達成共識。
Resource Managers (RMs)：執(zhí)行實際的事務操作并參與決策。
Registrar：記錄和維護事務的元數(shù)據(jù)，輔助事務狀態(tài)的查詢。
這些進程的功能分工確保了 Paxos Commit 協(xié)議在分布式環(huán)境中實現(xiàn)一致性和容錯，克服了傳統(tǒng) 2PC 的局限性。

End;