一、分佈式理論-一致性、2PC、3PC

引言

狹義的分佈式系統指由網絡鏈接的計算機系統，每一個節點獨立地承擔計算或存儲任務，節點間經過網絡協同工做。廣義的分佈式系統是一個相對的概念，正如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.

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

一致性(consensus)

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

《賭聖》，1990

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

1. 全認同(agreement): 全部N個節點都認同一個結果
2. 值合法(validity): 該結果必須由N個節點中的節點提出
3. 可結束(termination): 決議過程在必定時間內結束，不會無休止地進行下去

有人可能會說，決定何時在哪搓搓麻將，4我的商量一下就ok，這不很簡單嗎？

但就這樣看似簡單的事情，分佈式系統實現起來並不輕鬆，由於它面臨着這些問題：

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

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

 

我: 老王，今晚7點老地方，搓夠48圈不見不散！ ……

（次日凌晨3點）

隔壁老王: 沒問題！ // 消息延遲

我: ……

----------------------------------------------

我: 小張，今晚7點老地方，搓夠48圈不見不散！

小張: No ……

（兩小時後……）

小張: No problem！ // 宕機節點恢復 我: ……

-----------------------------------------------

我: 老李頭，今晚7點老地方，搓夠48圈不見不散！

老李: 必須的，大保健走起！ // 拜占庭將軍

（這是要打麻將呢？仍是要大保健？仍是一邊打麻將一邊大保健……）

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

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

1. 異步環境(asynchronous)下，節點宕機(fail-stop)
2. 異步環境(asynchronous)下，節點宕機恢復(fail-recover)、網絡分化(network partition)

2比1多了節點恢復、網絡分化的考量，於是對這兩種模型的理論研究和工程解決方案一定是不一樣的，在尚未明晰所要解決的問題前談解決方案都是一本正經地耍流氓。

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

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

《怦然心動 (Flipped)》，2010

工程實踐上根據具體的業務場景，或保證強一致(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宕機恢復。這引出兩個疑問：

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

相比2PC，3PC增長了一個準備提交(prepare to commit)階段來解決以上問題：

圖片截取自wikipedia

coordinator接收完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怎麼解決一致性問題。

閱讀前人對分佈式系統的各項理論研究，其中有嚴謹地推理、證實，有一種數學的美；觀現實中的分佈式系統實現，是綜合各類因素下妥協的結果。