分散式系統的核心問題

分散式系統的核心問題
主要內容:
一致性問題 共識問題

一致性:分散式叢集中多個服務節點,對給定的操作,根據給定的協議,對處理結果對外保持一致. 不在乎結果是否正確,而是保證對外呈現的狀態一致.所有節點失敗也是一種一致.

引起不一致的因素:
節點間網路通訊的不可靠,訊息延遲,訊息亂序,內容錯誤.
節點處理時間無法保證: 結果可能錯誤,或者節點當機.

滿足一致性的要求:
1. 有限時間完成請求的處理2.不同節點完成的結果相同.3決策的結果必須是某個節點提出的提案.

強一致性需要 順序保證. 時鐘

共識:對某一操作,達成一直的過程.通常達成這個一過程需要叢集中的節點進行廣播投票.
但是由於分散式節點間的不穩定: 網路不可靠,節點當機,假訊息等.達成共識並不容易.

針對如上不穩定的情況,把故障分為:非拜占庭錯誤(出現訊息不響應,但是訊息不會被篡改)和拜占庭錯誤(存在偽造訊息的情況).

共識演算法:
CFT類 針對非拜占庭錯誤有: PAXOS 演算法.Raft演算法.
容錯較好,處理快,保證不超過一半節點故障.
BFT類 針對拜占庭錯誤有: PBFT 確定性演算法,POW 工作量證明的概率演算法.

FLP不可能原理: 非同步系統,不存在 任意場景下都能實現共識的演算法.

分散式同步:系統各個節點時鐘誤差存在上限,訊息傳遞必須在規定時間內完成,否則認為失敗.(傳統的分散式中,統一時鐘,超時失敗等都是同步)

分散式非同步:系統各個節點時鐘存在較大差距,訊息傳遞時間任意長(無法判斷節點故障還是網路延遲)

CAP 一致性 :分散式計算系統不可能同時保證 強一致性,高可用性,高分割槽容忍性.
折中選擇:
弱化一致性:對結果不敏感的應用可以允許最終一致. CouchDB
弱化可用性:對結果一致性敏感,銀行,當系統故障時會拒絕服務.MongoDB , Redis,MapReduce 為此設計. PAXOS 等共識演算法主要處理這種情況. 可能存在無法提供可用結果的情況,同時允許部分節點離線.
弱化分割槽容忍性: 網路分割槽出現概率較小, 兩階段提交演算法,關係型資料庫,ZK主要考慮這種情況設計的.實踐中網路可用是雙通道,弱化網路不穩定因素.

PAXOS 演算法:
節點分為三種角色:
① 提案者:提出提案,系統提案都有自增ID,(往往是客戶端擔任)
② 接受者:對提出的提案進行投票(服務端)
③ 學習者:對投票傳播學習,不參與投票
約束條件:
①保證決議結果是正確的,不會出現錯誤.只有被提案者提出的提案才會被投票接受.一次執行中被多數接受的提案成為最終決議
②保證決議在有限時間內完成,決議總會產生,並且學習者會接受決議
過程:
Paxos演算法分為兩個階段。具體如下：
• 階段一：
(a) Proposer選擇一個提案編號N，然後向半數以上的Acceptor傳送編號為N的Prepare請求。
(b) 如果一個Acceptor收到一個編號為N的Prepare請求，且N大於該Acceptor已經響應過的所有Prepare請求的編號，那麼它就會將它已經接受過的編號最大的提案（如果有的話）作為響應反饋給Proposer，同時該Acceptor承諾不再接受任何編號小於N的提案。
• 階段二：
(a) 如果Proposer收到半數以上Acceptor對其發出的編號為N的Prepare請求的響應，那麼它就會傳送一個針對[N,V]提案的Accept請求給半數以上的Acceptor。注意：V就是收到的響應中編號最大的提案的value，如果響應中不包含任何提案，那麼V就由Proposer自己決定。
(b) 如果Acceptor收到一個針對編號為N的提案的Accept請求，只要該Acceptor沒有對編號大於N的Prepare請求做出過響應，它就接受該提案。

參考資料: https://www.cnblogs.com/linbingdong/p/6253479.html
RAFT演算法:

參考資料: http://www.cnblogs.com/linbingdong/p/6442673.html

PBFT 演算法:

POW演算法 :