Heidi Howard是劍橋大學計算機科學與技術繫系統研究小組的分佈式系統研究員，最近通過推特與全世界分享了一篇論文草稿。這篇文章引起了衆多讀者的注意，因爲它承諾爲一致性問題提供一個通用的解決方案，而且還利用了對不可變狀態的推理來實現這一點。每個服務器維護的狀態都是單調的。
4 月 16 日，Heidi的博士論文《一種通用的分佈式一致性方案》公開，發在 Twitter 上之後 Google 大神 Jeff Dean 還點了個贊。
在論文中Heidi對分佈式共識的代表算法Paxos提出了質疑，並證明了當前分佈式共識很多未解決的問題只是Paxos這個算法的問題，而不是因爲分佈式共識本身的問題。InfoQ的《The Morning Paper 》Adrian Colyer博士於3月份時就給我們做了一個非常詳細的論文解讀。
解讀
Heidi Howard最近通過推特與全世界分享了一篇論文草稿，這裏是相對應的博文。這篇文章引起了我的注意，因爲它承諾爲一致性問題提供一個通用的解決方案，而且還利用了對不可變狀態的推理來實現這一點。每個服務器維護的狀態都是單調的。
一致性問題是一個出了名的難題，Howard已經對這個領域進行了好幾年的深入研究。例如，它2016年發表的關於Flexible Paxos的論文。這裏追求的目標是找到一種統一的、易於理解的協議，它可以在不同的配置中實例化，允許根據情況做出不同的權衡。
本文重新研究了分佈式一致性問題，旨在改進性能和協議。我們是按如下方式開展工作的。一旦我們定義了一致性問題，我們就提出了一個通用一致性解決方案，它只使用不可變的狀態來實現關於正確性的更直觀的推理。隨後，我們證明了，Paxos和Fast Paxos都是通用一致性算法的實例，進而表明這兩種算法在方法上都是保守的。
分佈式一致性問題
我們有一組服務器（至少兩臺）需要就一個值達成一致。客戶端將要寫入的值作爲輸入，將服務器同意的值作爲輸出。
- 輸出值必須是客戶端的輸入值（例如，排除了總是輸出固定值的簡單解決方案）；
- 所有生成輸出的客戶端都必須輸出相同的值；
- 如果系統在足夠長的時間內是可靠和同步的，那麼所有客戶端最終都必須生成輸出。
請注意，我們在這裏討論的是“內部博弈”——這只是就單個值達成一致，而在實際部署中，我們可能會運行多輪協議來就一系列值達成一致。此外，我們在這裏假設客戶端集合和服務器都是固定的，並且客戶端知道服務器的存在。“客戶端”可能不是最終用戶客戶端，而更可能是使用一致性服務的系統流程。配置更改和成員資格時間段是我們可能會在實際部署中添加的另一個層，但在這裏超出了我們的討論範圍。
構建塊：不可變寄存器與仲裁
我們有一個固定的服務器集合，其中包含n臺服務器$S_0,+S_1,+…,+S_n$ 。每臺服務器都一個它可以寫入的磁帶，即一個一次寫入的持久性寄存器無限陣列：$R_0,+R_1,+…$.
最初，磁帶是空白的——所有寄存器都未寫入數據。一旦我們在寄存器槽中寫入一個值，它就永遠不會被更改。除了由客戶端提供的值，系統還有一個特殊值nil或$\bot$。
我們感興趣的是所有服務器上相同寄存器槽中的值集。寄存器集合$i$是所有服務器上所有寄存器$R_i$的集合。
如果一個寄存器集合中有足夠多的寄存器具有相同的（非$\bot$）值，那麼，我們會說服務器依據那個值做了決策。然而，一個寄存器集中有多少個寄存器就足夠了？這是我們需要作爲協議配置的一部分進行確定的。事實上，我們不僅要指定必須一致的寄存器值的數量，還要指定它們屬於哪個服務器。可以在服務器之間確定值的（非空）服務器子集稱爲“仲裁（quorum）”。更準確地講，“仲裁Q是一個（非空）服務器子集，這樣，如果所有服務器的同一個寄存器都有相同的（非空）值$v$，就可以說$v$就是決策值。”
仲裁這個詞通常與“大多數（majority）”這個詞緊密相關，但請注意，不一定非得如此。如果需要，該規範允許我們聲明只包含單個服務器的仲裁。詞典對“法定人數（quorum）”的定義是“議會或社團的最低成員人數，該成員必須出席其任何會議，以使該會議的會議記錄有效。”請注意，這裏也沒有仲裁成員資格部分重疊的要求（稍後將詳細介紹）。
一個寄存器可以關聯一組仲裁。也就是說，我們可以以寄存器集爲單位，準確地指定允許哪些服務器子集來決定一個值。例如：
我們究竟爲什麼要爲不同的寄存器集使用不同的仲裁集呢？我們最終會在單一值上達成一致。當我們研究如何在寄存器之上增加一個一致性協議層時，其原因就變得更加明顯了。
給定仲裁配置和寄存器集的寄存器值，我們就可以查看是否滿足任何仲裁併達成決策。
所有寄存器的狀態都可以用一個表表示，稱爲狀態表，其中每一列表示一個服務器的狀態，每一行表示一個寄存器集。通過一個狀態表把配置組合起來，我們就可以確定是否已經做出任何決策。
現在，我們要細心一點，記住狀態表是一個邏輯結構。每個服務器都知道自己寄存器的值，客戶端可以在從服務器接收信息時維護自己的全局狀態表視圖。但是，對於不可變的構造，我們知道，一旦客戶端收集了足夠的信息來判定一個值已確定，它就做出最終決策了。
四個規則
要遵守一些規則才能使其作爲一個協商一致的系統發揮作用。
- “仲裁一致（Quorum agreement）”：如果客戶端從仲裁服務器的相同寄存器集中讀取了$v$，那麼它只會輸出一個（非空）值$v$。
- 新值：如果客戶端的輸入值是$v$或者那個客戶端從寄存器讀取了$v$，那麼客戶端可能只寫一個（非空）值$v$。
- 當前決策：如果$v$是仲裁$Q+\in+Q_r$在寄存器集$r$中的決策，其中$s+\in+Q$，而且不存在一個值$v’$（$v+\neq+v’$）可以在寄存器集$r$中決策，那麼客戶端只能向服務器$s$上的寄存器$r$中寫入（非空）值$v$。
- 先前決策：如果不存在值$v’$（$v+\neq+v’$）可以在寄存器集0到$r±+1$中仲裁決策，那麼客戶端只能向寄存器$r$中寫入（非空）值。
前兩條規則非常簡單。規則3確保一個寄存器集所做的所有決策都具有相同的值，而規則4確保不同寄存器集所做的所有決策都具有相同的值。
遵守這些規則進一步增加了系統配置的限制。假如對於寄存器集i （${S_0}$和${S_1}$），我們有兩個仲裁。向$S_0$中的寄存器進行寫入的客戶端不知道其他客戶端可能向$S_1$寫入一個不同的值，因此，我們就無法遵守規則3。以下三種方式可以用於處理這種情況：
- 最簡單的方案是每個寄存器集只允許有一個仲裁；
- 在有多個仲裁的情況下，我們可以要求一個寄存器集的所有仲裁相交（即任意兩個仲裁至少有一個成員重疊）；
- 我們可以使用受客戶端限制的配置。在這裏，特定寄存器集的所有權被分配給特定的客戶端，這樣，只有該客戶端才能在該寄存器集中寫入值。如果該客戶端總是與其寫入的值保持一致，那麼就沒有什麼問題了。其中一種策略是輪流擁有寄存器集：
爲了遵守規則4，客戶端需要查看全局狀態表（即本地狀態表）的最新視圖，並確定是否已經或能夠通過更早的寄存器集做出任何決策。客戶端維護一個決策表，每個寄存器集的每個仲裁都有一個條目。這個表跟蹤客戶端對仲裁所做的決策。仲裁的可能值爲：
- ANY——決策可以是任意值（所有寄存器集的所有仲裁都從這個狀態開始）；
- MAYBE $v$——如果這個仲裁達成決策，那麼其值將是$v$；
- DECIDED $v$——$v$已經是仲裁的決策值（最終狀態）；
- NONE——仲裁無法做出決策（最終狀態）。
當客戶端接收到來自服務器的信息時，它會根據以下規則更新決策表：
- 如果客戶端從一個仲裁成員讀到了nil值，則該仲裁的狀態將設置爲NONE。
- 如果客戶端從寄存器集$r$讀取了一個非空值$v$，而且所有仲裁成員的值都相同，那麼仲裁的狀態就會設置爲DECIDED。否則，狀態設置爲MAYBE $v$。在後一種情況下，在之前的寄存器集中那些被設置爲ANY的同樣的仲裁也會設置成MAYBE$v$，但是，MAYBE$v’$（$v+\neq+v’$）值會被更新成NONE。
客戶端使用決策表來實現以下四條正確性規則：
我們的目的是使關於正確性的推理足夠直觀，不需要證明就能對安全性做出令人信服的說明。
無論如何，知道其中包含了證明，你會很高興，感興趣的話，可以查看附錄A。
不可變寄存器之上的Paxos
作爲論文的總結，這篇文章已經超出了我的目標篇幅，可能已經用了比原來的論文更多的單詞來解釋核心思想！我唯一可以辯解的是，在思考一致性問題的時候沒有捷徑。
本文主要是爲了展示，剛剛介紹的基於寄存器的方案可以被實例化來實現一些來自文獻的一致性方案，包括Paxos和Fast Paxos。我這裏沒有足夠的地方來做適當的評價，下面只是對核心Paxos算法的簡單介紹：
我們注意到，Paxos是通用一致性解決方案的一個保守示例。Paxos所使用的配置是所有寄存器集的絕大多數。Paxos還對所有寄存器集使用客戶端限制。第一段的目的是實現規則4，第二段的目的是實現規則1。
如果要弄清楚用於每個寄存器集的仲裁以及仲裁用於Paxos的哪個階段，可以看下Flexible Paxos。
總結
本文的第5部分展示瞭如何派生Fast Paxos，在第6部分中，你可以在配置空間中找到另外三個要點的簡要概述，分別是共置一致性、固定多數一致性和可重構一致性。
本文從一次寫寄存器的角度重新思考了分佈式一致性問題，提出了一種分佈式一致性的通用解決方案。我們已經證明，該解決方案不僅統一了現有的算法，包括Paxos和Fast Paxos，而且證明了這些算法的保守性，因爲它們的仲裁交叉要求和仲裁協議規則會被大大削弱。我們提出了三種新的協商一致算法，並提出了一些有趣的觀點，說明我們的抽象使得各種各樣的算法成爲可能，由此展示出我們的通用協商一致算法的強大。