什麼是分散式一致性領域的CALM定理？ -ACM

邏輯單調性的一致性（Consistency As Logical Monotonicity：CALM）：當且僅當問題是單調的時，問題才具有一致的、無需協調的分散式實現。
CALM定理是為了避免分散式事務機制中的協調機制，試圖實現如同沒有紅綠燈的交通路口，需要程式設計師對業務問題進行設計，保證問題是單調性的，也就是說，輸出結果與輸入資料的之間順序沒有關聯關係，輸入資料的前後順序不會影響輸出結果，典型案例如CRDT（無衝突的複製資料型別）。
 
分散式系統很棘手。多個不可靠的機器並行執行，它們在網路鏈路上以任意延遲相互傳送訊息。儘管存在這種混亂局面，我們如何才能確信這些系統能夠實現我們想要的功能？
這個問題應該引起我們的關注，因為我們今天使用的幾乎所有軟體都是分散式系統的一部分。手機上的應用程式與雲中的託管服務一起參與；它們一起形成一個分散式系統。託管服務本身是大規模分佈的系統，通常在遍佈全球的計算機上執行。大資料系統和大規模資料庫分佈在許多機器上。大多數科學計算和機器學習系統可跨多個處理器並行工作。甚至傳統的桌面作業系統和應用程式（例如電子表格和文書處理器）也與分散式後端服務緊密整合。
建立正確的分散式系統的挑戰越來越緊迫，但這並不是新問題。一種傳統的答案是透過記憶體一致性保證來降低這種複雜性-對記憶體（堆變數，資料庫金鑰等）的訪問以受控方式進行的保證。但是，用於執行這些保證的機制（協調協議）經常被批評為分散式系統的高效能，規模和可用性的障礙。
 

協調成本高
協調協議使自治的，鬆散耦合的機器可以共同決定如何控制基本行為，包括訪問共享記憶體的順序。這些協議是分散式計算中最聰明和被廣泛引用的思想之一。一些公知的技術包括的Paxos和兩階段提交（2PC）協議和基礎計算模型等散裝同步平行計算全域性障礙。
不幸的是，協調協議的開銷會使它們成為程式設計師的“禁果”。來自亞馬遜網路服務公司的詹姆斯·漢密爾頓（James Hamilton）用“一致性機制”一詞強力地說明了這一點，在其中使用了協調：
“成功的可伸縮性的首要原則是將一致性機制降低到最低程度，將它們移出關鍵路徑，將它們隱藏在系統很少訪問的角落，然後使應用程式開發人員儘可能地難以獲得許可。使用它們。” 
問題不在於協調很難實現，儘管確實如此。主要問題是協調會大大降低計算速度或完全停止計算。一些現代的全球規模的系統利用協調協議。Google Spanner交易資料庫是同時使用Paxos和2PC的著名示例。但是，這些協議的時延較高，大約為10ms-100ms。依賴於這些協議的全球級系統並不意味著應用程式能夠快速執行。協調等待時間問題也轉化為微觀規模。最近的工作表明，最新的多處理器鍵值儲存能將90％的時間用於協調。
一個名為Anna的無協調實現透過消除這種協調實現了兩個數量級以上的加速。我們可以像漢密爾頓建議的那樣更廣泛地避免協調嗎？什麼時候？

 
更大的前景：程式一致性
直到最近才解決了何時需要協調才能實現一致性的一般問題。
關於一致性的傳統工作集中在諸如線性化性和衝突可序列化性之類類的屬性上，這些屬性透過限制衝突的儲存器訪問的順序來確儲存儲器的一致性。這種傳統掩蓋了一個基本問題，即是否需要協調才能確保特定計劃結果的一致性？要從整體上解決問題，我們需要向上移動堆疊，預留低層的細節以支援程式語義。
交通交叉口提供了一個與現實世界類似的有用類比。為避免在繁忙的十字路口發生事故，我們經常安裝停車燈，以協調兩條相交道路的交通。但是，在這種情況下，協調並不是必不可少的事情：我們還可以透過為其中一條道路建造立交橋或隧道來預防事故。“交通路口問題”是具有免協調解決方案的示例。重要的是，無法透過巧妙地控制進入道路在地圖上重疊的關鍵區域的順序來找到解決方案。解決方案包括對道路進行工程設計，以完全避免協調。
對於交通交叉路口問題，事實證明，有一種解決方案可以完全避免協調。並非所有問題都使用這樣的解決方案。對於任何給定的計算問題，我們如何知道它是否具有免協調解決方案，或者是否需要協調以實現一致性？為了增強我們的直覺，我們考慮了分散式系統規範中的兩個幾乎相同的問題：兩者都涉及圖形的可到達性，但是一個沒有協調性，另一個則沒有，見下面
 

分散式死鎖檢測
分散式資料庫在分散式圖形中標識週期，以便檢測和修復死鎖。在傳統的資料庫系統中，事務T i可能正在等待另一個事務T j持有的鎖，而另一個事務T j可能正在等待另一個T i持有的鎖。死鎖檢測器透過分析有向圖來識別這種“等待”週期，在有向圖中，節點表示事務，而邊緣表示一個事務在鎖定佇列上等待另一個事務。死鎖是一個穩定的屬性：等待週期中的事務無法取得進展，因此週期中的所有邊緣都將無限期地保持。
在分散式資料庫中，等待圖的“本地”（單機）檢視僅包含全域性等待圖中邊的子集。在這種情況下，本地死鎖檢測器如何協同工作以識別全域性死鎖？

圖1顯示了跨越多臺計算機的等待週期。為了識別這種分散式死鎖，每臺機器都與其他機器交換其邊緣的副本以累積有關全域性圖的更多資訊。機器只要觀察到到目前為止已接收到的資訊中的週期，就可以在該週期的事務之間宣告死鎖。

我們可能會擔心由於此分散式計算中的訊息延遲或重新排序而導致的瞬時錯誤。本地探測器是否必須與其他機器配合以確保觀察到死鎖？在這種情況下，不需要協調。要看到這一點，請注意，一旦我們知道圖中存在迴圈，就知道新的邊永遠不可能使迴圈消失。例如，一旦機器1和機器2共同識別出T 1和T 3之間的死鎖，來自Machine 3的新資訊將不會改變這一事實。其他事實只能導致檢測到其他週期：每臺機器的輸出隨輸入單調增長。最後，如果最終在所有機器之間共享所有邊緣，則機器將基於完整圖形對結果達成共識。
  

分散式垃圾回收
分散式系統中的垃圾收集器必須在記憶體引用的分散式圖中標識無法訪問的物件。垃圾收集透過識別與系統執行時的“根”斷開連線的圖形元件來工作。“垃圾”屬性也是穩定的：一旦圖形元件與根的連線被刪除，該元件中的物件將不會被重新引用。
在分散式系統中，對物件的引用可以跨越機器。參考圖的區域性檢視僅包含全域性圖中邊的子集。多個本地垃圾收集器如何協同工作以標識真正無法訪問的物件？
請注意，一臺機器可能有一個本地物件，卻不知道該物件是否已連線到根目錄。機3和物件ø 4在圖2中形成的例子。但是，從根到物件的路徑仍然可能存在，該路徑由分佈在其他計算機上的邊組成。因此，每臺機器與其他機器交換邊的副本，以累積有關圖形的更多資訊。

和以前一樣，我們可能會擔心由於訊息延遲或重新排序而導致的錯誤。本地收集者可以自主宣告和取消分配垃圾嗎？在這裡，答案是不同的：確實需要協調！要看到這一點，請注意，基於不完整資訊的決策（例如，機器3判定圖2中的物件O 4不可達），可以透過隨後到達新的證明可達性的資訊（例如，邊緣Root→ O 1，O 1 → O 3，O 3 → O 4）。輸出不會隨輸入單調增長：可能需要撤消臨時“答案”。為了避免這種情況，機器必須確保在宣佈物件無法到達之前已經聽完了所有聽到的聲音。知道它聽到的一切的唯一方法是與所有其他機器（甚至沒有參考邊緣的機器）進行協調以建立事實。正如我們將要討論的，即使在沒有資料依賴的情況下，通訊的要求也是協調的標誌。
 

一致性的關鍵：單調性
這些示例使我們回到了適用於任何平行計算框架的基本問題。

問題：我們說，如果存在一個分散式實現（即解決問題的程式），而無需使用協調來計算一致的輸出，那麼計算問題就不會產生協調。什麼是無協調問題情況，情況之外有什麼問題？
偶然使用的協調與固有的協調需求之間是有區別的：前者是實施選擇的結果；後者是計算選擇的結果。後者是計算問題的性質。因此，我們的問題是可計算性之類問題之一，例如P對NP或可判定性。它詢問一個聰明的程式設計師不可能實現的是什麼。
 

定理1.作為邏輯單調性的一致性（Consistency As Logical Monotonicity：CALM）。當且僅當問題是單調的時，問題才具有一致的、無需協調的分散式實現。

非單調系統接收資訊的順序決定了它們如何來回切換狀態，這反過來又可以確定其最終狀態（我們將在後面的內容中看到）。購物車示例）。相比之下，單調的輸出僅取決於輸入的內容，而不取決於輸入的順序。
到目前為止，我們的討論仍停留在直覺上。下一部分提供了CALM定理的證明的草圖，包括對一致性和協調性定義的進一步討論。該證明使用了資料庫理論中的邏輯形式主義，並證明了將資料庫理論（ACM PODS）和分散式系統（ACM PODC）緊密結合在一起的好處。
 
證明過程點選標題見原文
 

CAP和CALM
Brewer的CAP定理14非正式地指出，系統只能顯示以下三個屬性中的兩個：一致性，可用性和分割槽容限。CAP是一個負面結果：它捕獲了通常無法實現的屬性。
CAP的表達達到了其目的，這是使設計者可以在更廣泛的系統和折衷方案中開放思想。現代CAP的目標應該是最大化對特定情況有意義的一致性和可用性的組合。
在這個領域，CALM是一個積極的成果：它界定了可以同時實現所有三個CAP屬性的問題類別。要看到這一點，請注意以下幾點：

• 觀察1.無協調性等同於分割槽下的可用性。

• 首先，在所有問題的範圍內，CAP都是負面結果：CALM確認了這一粗略結果，但在更細粒度上描繪了正面和負面的情況。使用融合作為一致性的定義，CALM顯示單調問題實際上可以同時滿足所有三個CAP屬性；非單調問題是不能解決的。
• CALM的關鍵見解是從程式結果的角度關注一致性，而不是衝突行動的傳統有序歷史（通常是儲存突變）。對要計算的問題的強調將重點從命令式實現轉移到宣告式輸出規範；這使我們可以提出關於可以進行哪些計算的問題。

分散式設計模式
無衝突的複製資料型別（CRDT）為單調程式設計模式（例如邏輯刪除）提供了物件導向的框架，通常用於複製狀態的上下文中。
CRDT是一種抽象的資料型別，可以使用關聯內部格中的交換，關聯，冪等聯接函式合併CRDT的兩個例項。最終，兩個CRDT副本的狀態可能會看到不同的輸入和順序，始終可以確定性地合併到一個新的最終狀態中，該狀態將合併兩個雙方看到的所有輸入。
 

Bloom程式語言
鼓勵良好的分散式設計模式的一種方法是使用專門圍繞這些模式的語言。Bloom是我們本著這種精神設計的一種程式語言。實際上，CALM猜想和Bloom語言是一起開發的。
Bloom的主要目標是使分散式系統更易於推理和程式設計。我們認為，一種適用於某個領域的好語言會掩蓋無關緊要的細節，並將那些重要的內容集中在一起。鑑於資料一致性是分散式計算中的核心挑戰，我們將Bloom設計為以資料為中心：系統狀態和事件均表示為命名資料，而計算則表示為對該資料的查詢。

詳細點選標題見原文