【蝦說區塊鏈】分佈式系統共識的FLP不可能原理與CAP猜測

image

歡迎收聽「蝦說區塊鏈」。如今區塊鏈這個概念在互聯網上至關火熱,這裏簡單作一個普及,不涉及項目推廣投資,單純地對區塊鏈相關基礎知識概念做一個說明講解。本人區塊鏈技術愛好者,結合相關區塊鏈資料總結整理了「蝦說區塊鏈」,也是本身一個學習筆記,涉及相關內容如理解有誤,也請及時指正。web

1

共識機制基礎概念

首先,共識機制在分佈式系統中是無解的,爲何說是無解,衆多的節點之間通訊,必然存在網絡自身不可靠的緣由、主機故障緣由、惡意操控等緣由,故是沒法保證明現徹底的共識,這裏不是筆者隨便下的結論,Fischer, Lynch 和 Patterson三位在1985年就提出了一個FLP不可能原理:在網絡可靠的前提下,任意節點失效,一個或者多個的最小化異步模型系統中,不可能存在一個解決一致性問題的肯定性算法。這三位的論文後來得到了Dijkstra獎。這一理論已被可靠的論證過,因此不用再花大力氣在異步分佈式系統中去設計一個徹底一致的共識算法。(這裏不深究FLP原理,有興趣能夠百度Lynch的<Distributed Algorithms>)算法

FLP說明在異步分佈式系統中徹底一致性是不可能的,但這是一個科學理論,應用到現實工程中,咱們能夠犧牲一些代價把不可能變成可能,這就是科學和工程的最大區別,就像你炒股吧,官方確定會告訴你股市有風險,入市需謹慎,但你確定認爲在你高超的操做下仍是能賺錢的。那在計算機工程領域中2000年 Eric Brewer在ACM 研討會提出猜測,CAP猜測,CAP拆解後就是一致性(Consistency)全部節點上的數據時刻保持同步、可用性(Availablity)每一個請求都能接受到一個響應不論響應成功或失敗、分區容忍性(Partition)系統內部有消息失效的狀況下仍能提供持續服務。數據庫

image

實際運用在工程環境下,適當取捨這三者,一致性、可用性和分區容錯性三者沒法在分佈式系統中被同時知足,而且最多隻能知足其中兩個。這樣就出現瞭如下三種狀況:安全

1)CA without P:若是不要求P(不容許分區),則C(強一致性)和A(可用性)是能夠保證的。但其實分區不是你想不想的問題,而是始終會存在,所以CA的系統更多的是容許分區後各子系統依然保持CA。Zookeeper爲此類設計。網絡

2)CP without A:若是不要求A(可用),至關於每一個請求都須要在Server之間強一致,而P(分區)會致使同步時間無限延長,如此CP也是能夠保證的。不少傳統的數據庫分佈式事務都屬於這種模式。MongoDB、Redis爲此類設計。架構

3)AP wihtout C:要高可用並容許分區,則需放棄一致性。一旦分區發生,節點之間可能會失去聯繫,爲了高可用,每一個節點只能用本地數據提供服務,而這樣會致使全局數據的不一致性。CouchDB、cassandra爲此類設計。異步

CAP猜測出現至今都一直存在不少質疑,有人提出概念的混亂、不適應數據庫事務架構等各類質疑,2002年對CAP猜測被證明爲一個定理,證實了CAP三者不可能同時知足,但沒有證實任意二者均可知足,對C\A\P做了更明確的聲明:分佈式

(論文原文:http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf),函數

最初這個辯證是在webserver集羣環境下的。學習

1)C:一致性被稱爲原子對象,任何的讀寫都應該看起來是「原子「的,或串行的。寫後面的讀必定能讀到前面寫的內容。全部的讀寫請求都好像被全局排序。

2)A:對任何非失敗節點都應該在有限時間內給出請求的迴應。(請求的可終止性)

3)P:容許節點之間丟失任意多的消息,當網絡分區發生時,節點之間的消息可能會徹底丟失。

質疑一直存在。2012年lynch重寫論文,再次對CAP作了進一步的解釋:

把CAP理論的證實侷限在原子讀寫的場景,並申明不支持數據庫事務之類的場景。

一致性場景不會引入用戶agent,只是發生在後臺集羣以內。

把分區容錯歸結爲一個對網絡環境的陳述,而非以前一個獨立條件。這實際上就是更加明確了概念。

引入了活性(liveness)和安全屬性(safety),在一個更抽象的概念下研究分佈式系統,並認爲CAP是活性與安全熟悉之間權衡的一個特例。其中的一致性屬於liveness,可用性屬於safety。

把CAP的研究推到一個更廣闊的空間:網絡存在同步、部分同步;一致性性的結果也從僅存在一個到存在N個(部分一致),引入了通訊週期round,並引用了其餘論文,給出了爲了保證N個一致性結果,至少須要通訊的round數。

(論文原文:http://groups.csail.mit.edu/tds/papers/Gilbert/Brewer2.pdf)

談論了以上CAP原理,目的就是爲了說明共識機制是相對的,目前沒有一種決對完美的共識機制,全部各類共識機制都是理論結合工程實踐產生的。

2

拜占庭問題

拜占庭將軍問題就會時常看到,拜占庭將軍問題是一個協議問題,拜占庭帝國軍隊的將軍們必須全體一致的決定是否攻擊某一支敵軍。問題是這些將軍在地理上是分隔開來的,而且將軍中存在叛徒。叛徒能夠任意行動以達到如下目標:欺騙某些將軍採起進攻行動;促成一個不是全部將軍都贊成的決定,如當將軍們不但願進攻時促成進攻行動;或者迷惑某些將軍,使他們沒法作出決定。若是叛徒達到了這些目的之一,則任何攻擊行動的結果都是註定要失敗的,只有徹底達成一致的努力才能得到勝利(來自百度百科)。

image

這裏不討論軍事問題,把拜占庭將軍問題引入到計算機領域,在分佈式系統中,網絡中各節點因爲硬件設備故障、網絡延時或故障、惡意攻擊致使整個系統中出現不可預知的錯誤。把拜占庭將軍問題嵌入到分佈式系統中說明:

前提:

1.網絡中各節點信道可靠。

2.網絡中節點數可知爲n。

分佈式網絡中的衆多節點,同時更新或者刪除數據,必須達到共識的狀態,可是有些節點會出現不肯定故障或者惡意篡改,致使分佈式節點數據不一致,這個問題現實中是不可避免的。那麼要求系統能正常運行,這裏引入一個容錯的概念,能夠在不徹底一致的狀態下,系統仍然能夠正常運行。

所謂的正常運行有兩種概念:

  1. 數據的正常更新後提供服務。

  2. 因爲故障節點過多數據不更新提供服務,再發起一次共識。

如何來定義這個正常運行,這個須要有一個取捨,由於結合實際應用不少因素須要考慮,理論的嚴謹和工程的取捨這個通常都會有權衡。下面說明經過容錯達成的正常運行。

設置一個變量x,節點數爲n,假設其中一個節點爲i。經過各類條件設置應用場景:

節點i發佈請求x,誠實節點收到的是(x一、x2...xi...xn)集合,這些集合內x值一致,那麼從i的誠實性考慮,有可能i是誠實節點、也有可能i自己就仍是惡意節點。

i節點是誠實節點,那麼其餘誠實節點也一樣發送x值。

結合1.2,咱們無論i節點的誠實性,全部誠實節點都收到同樣的x值集合。

image

這樣網絡中節點收到的請求更新一致,若是i是誠實節點,那麼保證了正常運行。這種狀況將1.2結合系統達到了一致性和正常運行的兩個要求。

可是這是理想化的狀態在現實網絡節點中剛纔的假設都是理想化的。經過執行流程來看下:

再假設三個前提:1.x發送均可正確傳達到其他節點中。2.接收節點知道發送節點。3.節點知道x消息完整。

那麼網絡中n個節點,惡意節點爲m個,那麼n>3m+1。

i發送x給每個節點,每一個節點收到x則更新、未收到默認就爲不操做。

每一個節點收到i發送x更新後,惡意節點m發送y其他節點,發送是一個遞歸過程。

每一個節點收集i發送x信息,惡意節點m接收x值,不發送至其他剩餘節點。

下面經過圖形說明:

image

這裏n=3,m=1,那麼節點i和節點B是誠實節點,可是B節點不知道應該是x仍是y是更新。再引入一個節點:

image

這種狀況下i、b、c節點是誠實節點,x值在b、c集合中出現2次,y出現一次,故達到了共識。這個前提是i是誠實節點,若是i自己就不是誠實節點,i發送不一樣三個值,那整個系統沒法共識。

n >3m+1 m=2 n=7

這個過程就會比較複雜了,假設a和d是惡意節點,那麼每一個誠實節點經過遞歸方式去接受其他節點的信息,而後收集的到信息集合中經過多數原則來肯定。

image

b 、c、e、f爲誠實節點加上i,系統達成共識。固然i若是是惡意節點,發送不一樣消息給下面節點,那麼共識將沒法成立,可是若是i發送是有一半是x值一半是不一樣值,能夠推理下。以上推理過程在拜占庭將軍問題中稱爲口頭協議。追溯咱們以前寫的三個假設中,若是接收者知道發送者,那麼就有書面協議。下面對書面協議再做說明:

所謂書面協議,就是網絡節點在傳輸過程當中添加一個簽名,任何節點能夠驗證簽名可靠性。

仍是用節點收到的數據集合v,i節點發送x值給各個節點,節點收到v(x),而後發送v(x):i給其他節點,若是收到的一串值中沒有v(x),那麼就把這個值添加到本身的v集合中。每一個節點收到值後,經過choice函數判斷。在口頭協議中三個節點當i節點發送不一樣值的時候沒法一致,那麼這裏加上簽名後能夠看下,以圖說明:

image

這種狀況下最後a、b節點接收信息後都是x、y那麼在系統中兩個節點信息一致。這就解決了3節點口頭協議不能完成一致的問題。若是n=4,m=2有興趣能夠再推理一次,結果也是一致的。

綜上所述,在拜占庭問題中n>3m+1能獲得保證,拜占庭將軍問題比較考驗整個推理,筆者也是根據本身理解寫了點介紹,有不對的請及時指正。

(音頻內容來源:「投河自盡的魚」)

如下是咱們的社區介紹,歡迎各類合做、交流、學習:)

image

點擊「閱讀原文」進入直播室聽專欄音頻

閱讀原文

相關文章
相關標籤/搜索