DB資料庫中分散式一致性演算法

mcxiaoracle發表於2022-06-21

一致性演算法 包括2PC 、3PC 、Paxos 、Raft 等四種:

2PC / 3PC 協議用於保證屬於多個資料分片上操作的原子性。
這些資料分片可能分佈在不同的伺服器上,2PC / 3PC 協議保證多臺伺服器上的操作要麼全部成功,要麼全部失敗

二階段提交2PC (Two-Phase Commit ): 用來保證分散式系統資料的一致性的一致性協議,大部分基於關係型資料庫的分散式事務處理都是採用二階段提交協議來完成。其優點是原理簡單且實現方便,缺點是同步阻塞、單點問題、資料不一致、太過保守。

2PC主要包括以下兩個階段:
第一階段:提交事務請求(投票階段)
第二階段:執行事務提交(執行階段)
為了避免在通知所有參與者提交事務時,其中一個參與者 crash 不一致時,就出現了三階段提交的方式。

三階段提交 3PC(Three- Phase Commi ):包括 CanCommit、PreCommit、doCommit 三個階段。顯而易見,三階段提交是在兩階段提交的基礎上增加了一個 preCommit 的過程,當所有參與者收到 preCommit 後,並不執行動作,直到收到 commit 或超過一定時間後才完成操作。
其優點是降低參與者阻塞範圍,並能夠在出現單點故障後繼續達成一致;缺點是引入preCommit 階段,在這個階段如果出現網路分割槽,協調者無法與參與者正常通訊,參與者依然會進行事務提交,造成資料不一致。


Paxos (強一致性)演算法屬於多數派演算法,主要目的是解決資料分片的單點問題, 透過該演算法可以讓整個叢集的節點對某個值的變更達成一致。任何一個節點都可以提出要修改某個資料的提案,是否透過這個提案取決於這個叢集中是否有超過半數的節點同意,因此Paxos演算法需要叢集中的節點必須是單數 。


Raft演算法是簡化版的Paxos, 定義了三種角色 Leader、Follower、Candidate:最初都是Follower,當Follower監聽不到Leader,就自動成為Candidate,然後發起投票選出新的Leader 。因此,Raft 劃分成三個子問題:

其有兩個基本過程:

① Leader選舉:每個 Candidate隨機經過一定時間都會提出選舉方案,最近階段中得票最多者被選為Leader;
② 同步log:Leader會找到系統中log(各種事件的發生記錄)最新的記錄,並強制所有的follow來重新整理到這個記錄。
Raft一致性演算法是透過選出一個leader來簡化日誌副本的管理,例如,日誌項(log entry)只允許從leader流向follower。




推薦閱讀:
連結:
來源:簡書










來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69949806/viewspace-2902054/,如需轉載,請註明出處,否則將追究法律責任。

相關文章