Paxos、Raft不是一致性演算法/協議?
作為網際網路中的一員,我們時常沉浸在“分散式”的氛圍當中——高可用、高可靠、高效能等等詞彙隨處可見,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強調的是對一個資料多個備份的讀寫一致性。
對於今天的知識點有什麼想說的嘛?不妨在留言區留下你的想法。
參考資料
淺談 CAP 和 Paxos 共識演算法 被誤用的“一致性” 分散式共識(Consensus):Viewstamped Replication、Raft以及Paxos
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69940568/viewspace-2680497/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- OceanBase的一致性協議為什麼選擇 Paxos 而不是 Raft?協議Raft
- 搞懂分散式技術2:分散式一致性協議與Paxos,Raft演算法分散式協議Raft演算法
- Paxos 一致性協議協議
- raft協議Raft協議
- 分散式技術專題-分散式協議演算法-帶你徹底認識Paxos演算法、Zab協議和Raft協議的原理和本質分散式協議演算法Raft
- 分散式協議與演算法-Paxos演算法分散式協議演算法
- Raft協議和ZAB協議Raft協議
- 使用GO實現Paxos分散式一致性協議Go分散式協議
- 分散式理論(六) - 一致性協議Raft分散式協議Raft
- 分散式一致性協議Raft全面詳解(建議收藏)分散式協議Raft
- Paxos協議其實說的就是Paxos協議
- 分散式協議與演算法-Raft演算法分散式協議演算法Raft
- 實現 Raft 協議Raft協議
- raft協議初識Raft協議
- raft協議詳解Raft協議
- Raft協議精解Raft協議
- Zookeeper的ZAB協議與Paxos協議區別協議
- 一致性協議淺析:從邏輯時鐘到Raft協議Raft
- 面試官:能聊聊Paxos演算法和ZAB協議嗎面試演算法協議
- 一文看盡 Raft 一致性協議的關鍵點Raft協議
- Paxos——分散式一致性演算法分散式演算法
- paxos分散式一致性演算法分散式演算法
- Raft協議學習筆記Raft協議筆記
- Raft 協議學習筆記Raft協議筆記
- raft演算法一致性的研究Raft演算法
- PolarDB-X 高可用儲存服務 基於 X-Paxos 一致性協議協議
- etcd套路(二)etcd核心之raft協議Raft協議
- 分散式理論(五) - 一致性演算法Paxos分散式演算法
- 理解分散式一致性與Raft演算法分散式Raft演算法
- 淺談分散式一致性演算法raft分散式演算法Raft
- Raft協議:通過TermId大的通過Raft協議
- consul 原始碼解析(一)raft 協議實現原始碼Raft協議
- 分散式一致性演算法-paxos詳解與分析分散式演算法
- 分散式基石|最難 paxos 和最易 raft ?分散式Raft
- 一致性協議(Consensus Algorithm)協議Go
- 快取一致性協議快取協議
- Zookeeper一致性協議——ZAB協議
- 區塊鏈共識演算法(4)分散式一致性演算法Paxos區塊鏈演算法分散式