分佈式理論基礎（一）一致性及解決一致性的兩種方式：2PC和3PC

1 一致性

1.1 簡述

一致性，是指對每一個節點一個數據的更新，整個集羣都知道更新，而且是一致的

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

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

 1.2 面臨着的問題

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

假設現實場景中也存在這樣的問題：

週五 我：晚上下班吃雞 週六凌晨 xc：好的 // 消息延遲
我：... --------------------------------- 我：晚上下班吃雞 xc：No (兩小時後) xc：No problem！ // 宕機節點恢復
我：... --------------------------------- 我：晚上下班吃雞 ... // 節點宕機

--------------------------------- 我：晚上下班吃雞 cx:好，咱們去大保健！ // 拜占庭將軍
我：...

 

 

2 2PC

2.1 簡述

2PC(tow phase commit)兩階段提交。

所謂的兩個階段是指：第一階段：準備階段(投票階段)和第二階段：提交階段（執行階段）。

咱們將提議的節點稱爲協調者(coordinator)，其餘參與決議節點稱爲參與者(participants, 或cohorts)。

 

2.2 階段1

在階段1中，協調者發起一個提議，分別問詢各參與者是否接受，以下圖：

 

 

 

2.3 階段2

在階段2中，協調者根據參與者的反饋，提交或停止事務，若是參與者所有贊成則提交，只要有一個參與者不一樣意就停止。

以下圖：

 

 

2.4 實例

下面咱們經過一個例子來講明兩階段提交協議的工做過程：

A組織B、C和D三我的去登山：若是全部人都贊成去登山，那麼活動將舉行；若是有一人不一樣意去登山，那麼活動將取消。用2PC算法解決該問題的過程以下：

首先A將成爲該活動的協調者，B、C和D將成爲該活動的參與者。

階段1：

　　①A發郵件給B、C和D，提出下週三去登山，問是否贊成。那麼此時A須要等待B、C和D的郵件。

　　②B、C和D分別查看本身的日程安排表。B、C發現本身在當日沒有活動安排，則發郵件告訴A它們贊成下週三去登山。因爲某種緣由， D白天沒有查看郵 件。那麼此時A、B和C均須要等待。到晚上的時候，D發現了A的郵件，而後查看日程安排，發現週三當天已經有別的安排，那麼D回覆A說活動取消吧。

階段2：

　　①此時A收到了全部活動參與者的郵件，而且A發現D下週三不能去登山。那麼A將發郵件通知B、C和D，下週三登山活動取消。

　　②此時B、C回覆A「太惋惜了」，D回覆A「很差意思」。至此該事務終止。

 

2.5 優缺點

在異步環境而且沒有節點宕機的模型下，2PC能夠知足全認同、值合法、可結束，是解決一致性問題的一種協議。從協調者接收到一次事務請求、發起提議到事務完成，通過2PC協議後增長了2次RTT(propose+commit)，帶來的時延增長相對較少。

二階段提交有幾個缺點：

• 同步阻塞問題。執行過程當中，全部參與節點都是事務阻塞型的。當參與者佔有公共資源時，其餘第三方節點訪問公共資源不得不處於阻塞狀態。
• 單點故障。因爲協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤爲在第二階段，協調者發生故障，那麼全部的參與者還都處於鎖定事務資源的狀態中，而沒法繼續完成事務操做。（若是是協調者掛掉，能夠從新選舉一個協調者，可是沒法解決由於協調者宕機致使的參與者處於阻塞狀態的問題）
• 數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求以後，發生了局部網絡異常或者在發送commit請求過程當中協調者發生了故障，這回致使只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求以後就會執行commit操做。可是其餘部分未接到commit請求的機器則沒法執行事務提交。因而整個分佈式系統便出現了數據部一致性的現象。
• 二階段沒法解決的問題：協調者再發出commit消息以後宕機，而惟一接收到這條消息的參與者同時也宕機了。那麼即便協調者經過選舉協議產生了新的協調者，這條事務的狀態也是不肯定的，沒人知道事務是否被已經提交。

 

2.6 2pc的衍生

2PC協議包含協調者和參與者，而且兩者都有發生問題的可能性。假如協調者發生問題，咱們能夠選出另外一個協調者來提交事務。例如，班長組織活動，若是班長生病了，咱們能夠請副班長來組織。若是協調者出問題，那麼事務將不會取消。例如，班級活動但願每一個人都能去，假若有一位同窗不能去了，那麼直接取消活動便可。或者，若是大多數人去的話那麼活動如期舉行（2PC變種）。

 

3 3pc

3.1 簡述

三階段提交（Three-phase commit），是二階段提交（2PC）的改進版本。

與兩階段提交不一樣的是，三階段提交有兩個改動點。

• 引入超時機制。同時在協調者和參與者中都引入超時機制。
• 在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段以前各參與節點的狀態是一致的。

 也就是說，除了引入超時機制以外，3PC把2PC的準備階段再次一分爲二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。

 

3.2 CanCommit階段

3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者發送commit請求，參與者若是能夠提交就返回Yes響應，不然返回No響應。

• 事務詢問 協調者向參與者發送CanCommit請求。詢問是否能夠執行事務提交操做。而後開始等待參與者的響應。
• 響應反饋 參與者接到CanCommit請求以後，正常狀況下，若是其自身認爲能夠順利執行事務，則返回Yes響應，並進入預備狀態。不然反饋No

 

3.3 PreCommit階段

協調者根據參與者的反應狀況來決定是否能夠記性事務的PreCommit操做。根據響應狀況，有如下兩種可能。

假如協調者從全部的參與者得到的反饋都是Yes響應，那麼就會執行事務的預執行。

• 發送預提交請求 協調者向參與者發送PreCommit請求，並進入Prepared階段。
• 事務預提交 參與者接收到PreCommit請求後，會執行事務操做，並將undo和redo信息記錄到事務日誌中。
• 響應反饋 若是參與者成功的執行了事務操做，則返回ACK響應，同時開始等待最終指令。

假若有任何一個參與者向協調者發送了No響應，或者等待超時以後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷。

• 發送中斷請求 協調者向全部參與者發送abort請求。
• 中斷事務 參與者收到來自協調者的abort請求以後（或超時以後，仍未收到協調者的請求），執行事務的中斷。

 

3.4 doCommit階段

該階段進行真正的事務提交，也能夠分爲如下兩種狀況。

執行提交

• 發送提交請求 協調接收到參與者發送的ACK響應，那麼他將從預提交狀態進入到提交狀態。並向全部參與者發送doCommit請求。
• 事務提交 參與者接收到doCommit請求以後，執行正式的事務提交。並在完成事務提交以後釋放全部事務資源。
• 響應反饋 事務提交完以後，向協調者發送Ack響應。
• 完成事務 協調者接收到全部參與者的ack響應以後，完成事務。

中斷事務

協調者沒有接收到參與者發送的ACK響應（多是接受者發送的不是ACK響應，也可能響應超時），那麼就會執行中斷事務。

• 發送中斷請求 協調者向全部參與者發送abort請求
• 事務回滾 參與者接收到abort請求以後，利用其在階段二記錄的undo信息來執行事務的回滾操做，並在完成回滾以後釋放全部的事務資源。
• 反饋結果 參與者完成事務回滾以後，向協調者發送ACK消息
• 中斷事務 協調者接收到參與者反饋的ACK消息以後，執行事務的中斷。

 

3.5 2pc和3pc的區別

相對於2PC，3PC主要解決的單點故障問題，並減小阻塞，由於一旦參與者沒法及時收到來自協調者的信息以後，他會默認執行commit。而不會一直持有事務資源並處於阻塞狀態。可是這種機制也會致使數據一致性問題，由於，因爲網絡緣由，協調者發送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時以後執行了commit操做。這樣就和其餘接到abort命令並執行回滾的參與者之間存在數據不一致的狀況。

在2PC中一個參與者的狀態只有它本身和協調者知曉，假如協調者提議後自身宕機，在協調者備份啓用前一個參與者又宕機，其餘參與者就會進入既不能回滾、又不能強制commit的阻塞狀態，直到參與者宕機恢復。

參與者若是在不一樣階段宕機，咱們來看看3PC如何應對：

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