大佬,我懵了!Paxos、Raft不是一致性算法/協議?

2021-02-21 佔小狼的博客

作為網際網路中的一員，我們時常沉浸在「分布式」的氛圍當中——高可用、高可靠、高性能等等詞彙隨處可見，CAP、BASE、2PC、Paxos、Raft等等名詞也能信手捏來。不過，有些詞在我們「並不嚴謹」的傳播中逐漸被誤用了，或者說含糊不清了。今天，我們來簡單聊聊「Consistency」這個詞，即一致性。

Paxos、Raft等通常被誤稱為「一致性算法」。但是「一致性（Consistency）」和「共識（Consensus）」並不是同一個概念。Paxos、Raft等其實都是共識（Consensus）算法。

Leslie Lamport於1998年在ACM Transactions on Computer Systems上發表了一篇《The Part-Time Parliament》[1]的文章，這是Paxos算法第一次公開發表。但是發表之後，很多人還是覺得原來那篇太難理解了，之後Lamport又寫了一篇《Paxos Made Simple》[2]，當我們想要學習一下Paxos的時候，可以直接看看這篇。

回到正題，我們在《Paxos Made Simple》中搜索「Consistency」一詞，如下圖所示，其實是毫無匹配結果的。

反觀，我們搜索「Consensus」一詞的時候，卻出現了很多匹配項。

也就是說，Paxos論文通篇提都沒提Consistency一詞，何來的「Paxos is a consistency algorithm」的說法。

與此類似的是，在Raft論文《In Search of an Understandable Consensus Algorithm (Extended Version)》[3]中開頭就對Raft給出了明確的定義：Raft is a consensus algorithm....，注意這裡是consensus，而不是consistency。

這時候我們不妨再打開字典。乍眼一看，字典中Consistency和Consenus譯意接近，都有「一致」的含義，但是仔細深究又有所不同：Consistency：一致性，Consensus：共識、一致的意見。

從專業的角度來講，我們通常所說的一致性（Consistency）在分布式系統中指的是對於同一個數據的多個副本，其對外表現的數據一致性，如強一致性、順序一致性、最終一致性等，都是用來描述副本問題中的一致性的。而共識（Consensus）則不同，簡單來說，共識問題是要經過某種算法使多個節點達成相同狀態的一個過程。一致性強調結果，共識強調過程。

《分布式系統概念與設計》一書中對共識問題進行了如下定義：為達到共識，每個進程 pi 最初處於未決（undecided）狀態，並且提議集合D中的一個值 vi 。進程之間互相通信，交換值。然後，每個進程設置一個決定變量（decision variable）di 的值。在這種情況下，它進入決定（decided）狀態。在此狀態下，他不再改變di。

下圖中給出了參與一個共識算法的3個進程。兩個進程提議「繼續」， 第三個進程提議「放棄」但隨後崩潰。保持正確的兩個進程都決定「繼續」。（其中i = 1, 2, ……, N; j = 1, 2, ……, N。）

共識算法的要求是在每次執行中滿足以下條件：

協定性：所有正確進程的決定值都相同，即如果 pi 和 pj 是正確的並且已進入決定狀態，那麼 di = dj。完整性：如果正確的進程都提議同一個值，那麼處於決定狀態的任何正確進程已選擇了該值。

共識問題中所有的節點要最終達成共識，由於最終目標是所有節點都要達成一致，所以根本不存在一致性強弱之分。所以，以後我們看到「Paxos是一個強一致性算法」、「Raft是一個強一致性協議」等類似說法的時候，我們更要以一種「審視」的眼光去看待後面的內容。

在我們大多數人的大多數工作內容中，一致性（Consistency）與共識（Consensus）的差別其實無關痛癢。但是如果我們想抬高一個維度，深入的去研究一下分布式領域的內容，那麼這些最基礎的概念如果區分不清楚的話，會對後面的學習過程產生很大的阻礙。

越是相近的詞彙，越要清楚的區分。就算是同一個單詞，也會有不同的含義解析，比如CAP和ACID中的C都是Consistency的縮寫，但這兩者在各自場景下的含義也並不相同。

ACID的C指的是事務中的一致性，在一系列對數據修改的操作中，保證數據的正確性。即數據在事務期間的多個操作中，數據不會憑空的消失或增加，數據的每一個增刪改操作都是有因果關係的。比如用戶A向用戶B轉了200塊錢，不會出現用戶A扣了款，而用戶B沒有收到的情況。在分布式環境中，多服務之間的複製是異步，需要一定耗時，不會瞬間完成。在某個服務節點的數據修改之後，到同步到其它服務節點之間存在一定的時間間隔，如果在這個間隔內有並發讀請求過來，而這些請求又負載均衡到多個節點，可能會出現從多個節點數據不一致的情況，因為請求有可能會落到還沒完成數據同步的節點上。CAP中的C就是為了做到在分布式環境中讀取的數據是一致的。

總的來說，ACID的C著重強調單資料庫事務操作時，要保證數據的完整和正確性，而CAP理論中的C強調的是對一個數據多個備份的讀寫一致性。

對於今天的知識點有什麼想說的嘛？不妨在留言區留下你的想法。

參考資料http://lamport.azurewebsites.net/pubs/lamport-paxos.pdfhttp://lamport.azurewebsites.net/pubs/paxos-simple.pdfhttps://raft.github.io/raft.pdf分布式共識(Consensus)：Viewstamped Replication、Raft以及Paxos

相關焦點

  • 談談paxos, multi-paxos, raft
    本文假設你已經看過了paxos make simpe, paxos make live, 關於raft 你看過對應的paper, multi-paxos 其實我覺得介紹的最好的還是Diego Ongaro
  • 分布式|Paxos和Raft複習
    https://www.infoq.cn/article/wechat-paxosstore-paxos-algorithm-protocol/http://www.vldb.org/pvldb/vol10/p1730-lin.pdfhttps://raft.github.io/raft.pdfhttps://github.com/etcd-io
  • 一文看懂Paxos和Raft算法
    以上故事改編自赫赫有名的Leslie Lamport（LaTeX中的La）的論文The Part-Time Parliament （ http://research.microsoft.com/users/lamport/pubs/lamport-paxos.pdf ）就是這篇論文提出了Paxos算法。為什麼叫Paxos？
  • hashicorp Raft 代碼閱讀筆記
    我的hashicorp raft閱讀筆記分為4部分，本文主要為前2部分：1、 概況2、 hashicorp raft 核心數據結構3、 hashicorp raft 對典型問題的處理：領導選舉、日誌複製4、 處理流程：CRUD操作是如何落地的一、概覽分布式共識算法CAP理論 根據CAP理論：一致性(Consistency
  • 分布式一致性算法:Raft 算法
    Raft 算法是可以用來替代 Paxos 算法的分布式一致性算法，而且 raft 算法比 Paxos 算法更易懂且更容易實現。本文對 raft 論文進行翻譯，希望能有助於讀者更方便地理解 raft 的思想。
  • Paxos一致性協議的基本流程
    分布式學習筆記——一致性協議（2)PaxosGoogle Chubby的作者Mike Burrows說過，這個世界上只有一種一致性算法，那就是Paxos，其它都是殘次品。paxos基本流程在2PC或3PC中，主要有協調者和參與者兩種角色，在Paxos中，有三種角色，提議者，接收者和學習者。
  • 一文搞懂Raft算法
    raft是工程上使用較為廣泛的強一致性、去中心化、高可用的分布式協議。
  • 基於Raft 深度優化,騰訊雲金融級消息隊列 CMQ 高可靠算法詳解
    傳統的主備強同步模式雖然可以保證一致性，但一旦機器故障或網絡分區系統將變得不可用。paxos 和 raft 等一致性算法的提出，彌補了這一缺陷。它們在保證 CP 的前提下，只要求大多數節點可以正常互聯，系統便可以一直處於可用狀態，可用性上顯著提高。paxos 的理論性偏強，開發者需要自己處理很多細節，這也是它有很多變種的原因，相對而言 raft 更易理解和工程化，一經提出便廣受歡迎。
  • X-Paxos —— 阿里巴巴的高性能分布式強一致Paxos獨立基礎庫
    Paxos是最重要的分布式一致性算法，很多人都把它作為「分布式一致性協議」的代名詞(Mike Burrows, inventor of the Chubby service at Google, says that 「there is only one consensus protocol, and that’s Paxos」)。
  • 分布式一致性機制整理
    現在主流的一致性協議一般都選擇的是弱一致性的特殊版本：最終一致性。下面就從分布式系統的基本原則講起，再整理一些遵循這些原則的協議或者機制，爭取通俗易懂。但是要真正實施起來把這些協議落地，可不是一片文章能說清楚的，有太多的細節，要自己去看論文吶（順著維基百科找就行了）。
  • 深度解析 Raft 分布式一致性協議(長文)
    弱一致性涵蓋的範圍較廣，涉及根據實際場景進行諸多取捨，不在 Raft 系列的討論目標範圍內。所謂的強一致性（線性一致性）並不是指集群中所有節點在任一時刻的狀態必須完全一致，而是指一個目標，即讓一個分布式系統看起來只有一個數據副本，並且讀寫操作都是原子的，這樣應用層就可以忽略系統底層多個數據副本間的同步問題。
  • 共識算法系列之一:raft和pbft算法
    關於兩個算法的適用環境和最大容錯節點數，前文已經做過闡述，這裡不再細說。而對於算法通信複雜度，為什麼 raft 是 o（n），而 pbft 是 o（n^2）呢？這裡主要考慮算法的共識過程。對於 raft 算法，核心共識過程是日誌複製這個過程，這個過程分兩個階段，一個是日誌記錄，一個是提交數據。
  • 【譯】Raft 學生指南(一)
    過去的幾個月裡，我擔任了 MIT 的6.824 分布式系統[1]課程的助教。這門課在早期有一些基於 Paxos 一致性算法的實驗，但是今年，我們決定將其轉移到Raft[2]。Raft 是「以易於理解為目標而被設計出來的」，並且，我們的期望這個改變可以使學生的生活變得更加輕鬆。
  • 強一致、高可用、自動容災能力背後,阿里X-Paxos的應用實踐
    Paxos(分布式一致性算法)作為分布式系統的基石，一直都是計算機系統工程領域的熱門話題。Paxos 號稱是最難理解的算法，其實當真這麼困難麼?X-Paxos 是阿里巴巴資料庫團隊面向高性能、全球部署以及阿里業務特徵等需求，實現的一個高性能分布式強一致的 Paxos 獨立基礎庫。
  • 圖解超難理解的 Paxos 算法
    ，其中 Paxos 算法是 Leslie Lamport 於 1990 年提出的共識算法，不幸的是採用希臘民主議會的比喻很明顯失敗了，Lamport 像寫小說一樣，把一個複雜的數學問題弄成了一篇帶有考古色彩的歷史小說。
  • 圖解什麼是一致性哈希算法
    一致性，咱懂哈希算法，咱也懂一致性+哈希算法  什麼鬼？雖然我大白腦袋比較空，但是我不信所有的網友都知道這個術語，於是在知乎找到個問題，還以為是我寫的呢：3.分布式系統和一致性哈希要理解一致性哈希算法就需要知道分布式系統的一些特點。
  • Raft實戰——線性一致性實現方法及性能優化
    其次介紹基於 Raft 協議實現工程系統時，如何來保證線性一致性；最後介紹 Raft 針對一致性所做的讀性能優化的具體策略。系列前文快速連結：在前面5篇文章中，我們分別介紹了《Raft 基本概念》、《Raft 選主機制》、《Raft 基於日誌複製實現狀態機機制》、《Raft 選主及狀態機維護的安全性》、《Raft 集群變更防腦裂 & 解決數據膨脹》，《線性一致性概念介紹》，系統學習 Raft 協議建議從頭閱讀。
  • 面試官:聊聊 etcd 中的 Raft 吧
    Raft：https://en.wikipedia.org/wiki/Raft_(computer_science "Raft") 是近年來比較流行的一個一致性算法。它的原理比較容易理解，網上也有很多相關的介紹，因此這裡我就不再囉嗦原理了，而是打算以 raft 在 etcd 中的實現1[1]為例，從工程的角度來講講這個算法的一個具體實現，畢竟了解原理只算是「紙上談兵」，離真正能把它應用起來還有很長一段距離。