分佈式系統理論基礎一： 一致性、2PC和3PC

請戳GitHub原文: github.com/wangzhiwubi…

引言

狹義的分佈式系統指由網絡鏈接的計算機系統，每一個節點獨立地承擔計算或存儲任務，節點間經過網絡協同工做。廣義的分佈式系統是一個相對的概念，正如Leslie Lamport所說[1]： What is a distributed systeme. Distribution is in the eye of the beholder.To the user sitting at the keyboard, his IBM personal computer is a nondistributed system. To a flea crawling around on the circuit board, or to the engineer who designed it, it's very much a distributed system.

公衆號

• 全網惟一一個從0開始幫助Java開發者轉作大數據領域的公衆號~

• 公衆號大數據技術與架構或者搜索import_bigdata關注，大數據學習路線最新更新，已經有不少小夥伴加入了~

一致性是分佈式理論中的根本性問題，近半個世紀以來，科學家們圍繞着一致性問題提出了不少理論模型，依據這些理論模型，業界也出現了不少工程實踐投影。下面咱們從一致性問題、特定條件下解決一致性問題的兩種方法(2PC、3PC)入門，瞭解最基礎的分佈式系統理論。

一致性(consensus)

何爲一致性問題？簡單而言，一致性問題就是相互獨立的節點之間如何達成一項決議的問題。分佈式系統中，進行數據庫事務提交(commit transaction)、Leader選舉、序列號生成等都會遇到一致性問題。這個問題在咱們的平常生活中也很常見，好比牌友怎麼商定幾點在哪打幾圈麻將：

假設一個具備N個節點的分佈式系統，當其知足如下條件時，咱們說這個系統知足一致性：

• 全認同(agreement): 全部N個節點都認同一個結果

• 值合法(validity): 該結果必須由N個節點中的節點提出

• 可結束(termination): 決議過程在必定時間內結束，不會無休止地進行下去

有人可能會說，決定何時在哪搓搓麻將，4我的商量一下就ok，這不很簡單嗎？   但就這樣看似簡單的事情，分佈式系統實現起來並不輕鬆，由於它面臨着這些問題：

• 消息傳遞異步無序(asynchronous): 現實網絡不是一個可靠的信道，存在消息延時、丟失，節點間消息傳遞作不到同步有序(synchronous)
• 節點宕機(fail-stop): 節點持續宕機，不會恢復
• 節點宕機恢復(fail-recover): 節點宕機一段時間後恢復，在分佈式系統中最多見
• 網絡分化(network partition): 網絡鏈路出現問題，將N個節點隔離成多個部分
• 拜占庭將軍問題(byzantine failure): 節點或宕機或邏輯失敗，甚至不按套路出牌拋出干擾決議的信息

假設現實場景中也存在這樣的問題，咱們看看結果會怎樣：

還能不能一塊兒愉快地玩耍...

咱們把以上所列的問題稱爲系統模型(system model)，討論分佈式系統理論和工程實踐的時候，必先劃定模型。例若有如下兩種模型：

異步環境(asynchronous)下，節點宕機(fail-stop) 異步環境(asynchronous)下，節點宕機恢復(fail-recover)、網絡分化(network partition) 2比1多了節點恢復、網絡分化的考量，於是對這兩種模型的理論研究和工程解決方案一定是不一樣的，在尚未明晰所要解決的問題前談解決方案都是一本正經地耍流氓。

一致性還具有兩個屬性，一個是強一致(safety)，它要求全部節點狀態一致、共進退；一個是可用(liveness)，它要求分佈式系統24x7無間斷對外服務。FLP定理(FLP impossibility)已經證實在一個收窄的模型中(異步環境並只存在節點宕機)，不能同時知足 safety 和 liveness。

FLP定理是分佈式系統理論中的基礎理論，正如物理學中的能量守恆定律完全否認了永動機的存在，FLP定理否認了同時知足safety 和 liveness 的一致性協議的存在。

工程實踐上根據具體的業務場景，或保證強一致(safety)，或在節點宕機、網絡分化的時候保證可用(liveness)。2PC、3PC是相對簡單的解決一致性問題的協議，下面咱們就來了解2PC和3PC。

2PC

2PC(tow phase commit)兩階段提交[5]顧名思義它分紅兩個階段，先由一方進行提議(propose)並收集其餘節點的反饋(vote)，再根據反饋決定提交(commit)或停止(abort)事務。咱們將提議的節點稱爲協調者(coordinator)，其餘參與決議節點稱爲參與者(participants, 或cohorts)：

2PC, phase one 在階段1中，coordinator發起一個提議，分別問詢各participant是否接受。

2PC, phase two 在階段2中，coordinator根據participant的反饋，提交或停止事務，若是participant所有贊成則提交，只要有一個participant不一樣意就停止。   在異步環境(asynchronous)而且沒有節點宕機(fail-stop)的模型下，2PC能夠知足全認同、值合法、可結束，是解決一致性問題的一種協議。但若是再加上節點宕機(fail-recover)的考慮，2PC是否還能解決一致性問題呢？   coordinator若是在發起提議後宕機，那麼participant將進入阻塞(block)狀態、一直等待coordinator迴應以完成該次決議。這時須要另外一角色把系統從不可結束的狀態中帶出來，咱們把新增的這一角色叫協調者備份(coordinator watchdog)。coordinator宕機必定時間後，watchdog接替原coordinator工做，經過問詢(query) 各participant的狀態，決定階段2是提交仍是停止。這也要求 coordinator/participant 記錄(logging)歷史狀態，以備coordinator宕機後watchdog對participant查詢、coordinator宕機恢復後從新找回狀態。   從coordinator接收到一次事務請求、發起提議到事務完成，通過2PC協議後增長了2次RTT(propose+commit)，帶來的時延(latency)增長相對較少。

3PC

3PC(three phase commit)即三階段提交[6][7]，既然2PC能夠在異步網絡+節點宕機恢復的模型下實現一致性，那還須要3PC作什麼，3PC是什麼鬼？

在2PC中一個participant的狀態只有它本身和coordinator知曉，假如coordinator提議後自身宕機，在watchdog啓用前一個participant又宕機，其餘participant就會進入既不能回滾、又不能強制commit的阻塞狀態，直到participant宕機恢復。這引出兩個疑問：

能不能去掉阻塞，使系統能夠在commit/abort前回滾(rollback)到決議發起前的初始狀態 當次決議中，participant間能不能相互知道對方的狀態，又或者participant間根本不依賴對方的狀態

圖片截取自wikipediacoordinator 接收完participant的反饋(vote)以後，進入階段2，給各個participant發送準備提交(prepare to commit)指令。participant接到準備提交指令後能夠鎖資源，但要求相關操做必須可回滾。coordinator接收完確認(ACK)後進入階段三、進行commit/abort，3PC的階段3與2PC的階段2無異。協調者備份(coordinator watchdog)、狀態記錄(logging)一樣應用在3PC。   participant若是在不一樣階段宕機，咱們來看看3PC如何應對：

• 階段1: coordinator或watchdog未收到宕機participant的vote，直接停止事務；宕機的participant恢復後，讀取logging發現未發出同意vote，自行停止該次事務
• 階段2: coordinator未收到宕機participant的precommit ACK，但由於以前已經收到了宕機participant的同意反饋(否則也不會進入到階段2)，coordinator進行commit；watchdog能夠經過問詢其餘participant得到這些信息，過程同理；宕機的participant恢復後發現收到precommit或已經發出同意vote，則自行commit該次事務
• 階段3: 即使coordinator或watchdog未收到宕機participant的commit ACK，也結束該次事務；宕機的participant恢復後發現收到commit或者precommit，也將自行commit該次事務

由於有了準備提交(prepare to commit)階段，3PC的事務處理延時也增長了1個RTT，變爲3個RTT(propose+precommit+commit)，可是它防止participant宕機後整個系統進入阻塞態，加強了系統的可用性，對一些現實業務場景是很是值得的。

小結

以上介紹了分佈式系統理論中的部分基礎知識，闡述了一致性(consensus)的定義和實現一致性所要面臨的問題，最後討論在異步網絡(asynchronous)、節點宕機恢復(fail-recover)模型下2PC、3PC怎麼解決一致性問題。   閱讀前人對分佈式系統的各項理論研究，其中有嚴謹地推理、證實，有一種數學的美；觀現實中的分佈式系統實現，是綜合各類因素下妥協的結果。

參考文獻

[1] Solved Problems, Unsolved Problems and Problems in Concurrency, Leslie Lamport, 1983 [2] The Byzantine Generals Problem, Leslie Lamport,Robert Shostak and Marshall Pease, 1982 [3] Impossibility of Distributed Consensus with One Faulty Process, Fischer, Lynch and Patterson, 1985 [4] FLP Impossibility的證實, Daniel Wu, 2015 [5] Consensus Protocols: Two-Phase Commit, Henry Robinson, 2008 [6] Consensus Protocols: Three-phase Commit, Henry Robinson, 2008 [7] Three-phase commit protocol, Wikipedia

請戳GitHub原文: https://github.com/wangzhiwubigdata/God-Of-BigData

                   關注公衆號,內推,面試,資源下載,關注更多大數據技術~
                   大數據成神之路~預計更新500+篇文章，已經更新50+篇~ 
複製代碼