1. 程式人生 > >【一致性協議演算法】2PC和3PC

【一致性協議演算法】2PC和3PC

分散式一致性:2PC和3PC

在一個分散式系統中,為了保持分散式叢集中所有節點事務的一致性,需要引入一個稱為“協調者”的元件來同一排程所有的分散式節點的執行邏輯,這些被排程的分散式節點被稱為“參與者”。協調者負責排程參與者的行為,並最終決定這些參與者是否要把事務真正進行提交。

1. 2PC-兩階段提交協議(強一致性演算法)

二階段提交協議是將事務的提交過程分成了兩個階段來進行處理:投票階段、執行階段

階段一:提交事務請求(投票階段)

1 . 協調者向所有參與者傳送事務內容,詢問是否可以執行事務提交操作,並等待所有參與者響應。

2 . 各個參與結點執行事務操作,並將Undo 和 Redo 資訊寫入事務日誌中。

3 .各個參與結點向協調者返回事務詢問的響應(參與者成功執行了事務就返回YES,否則表示事務不可執行並返回NO)

階段一類似於協調者組織所有的參與者對某個事務操作做了一個投票過程,各個參與者表明是否可以進行事務的提交過程。

階段二:執行事務提交(執行階段)

根據階段一的投票過程的結果,決定是否進行事務提交操作,也就是包括兩種結果:

執行事務提交(投票通過)

1 . 傳送提交請求:協調者從所有參與者那裡得到的反饋都是YES,那麼協調者就向所有的參與者傳送commit命令。

2 . 事務提交:參與飢餓接收到commit命令後執行正式的事務提交操作,並在完成commit之後釋放資源

3 . 反饋提交結果:參與者完成commit之後向協調者傳送ACK訊號

4 . 協調者收到所有參與者返回的ACK訊息後,事務完成。

中斷事務

如果出現:任何一個參與者在投票階段返回NO;或則協調者等待超時之後,參與者仍然沒有接收到所有參與者的反饋資訊;這是就會中斷事務回滾。

1 . 傳送回滾請求:協調者向所有參與者傳送 Rollback 請求。

2 . 參與者收到 Rollback 請求之後利用再階段一保留的 Undo 資訊執行事務回滾。

3 . 參與者完成回滾之後反饋回滾結果ACK訊號給協調者。

4 . 協調者收到所有參與者的反饋ACK訊號之後,完成事務中斷。

二階段提交協議,就是把事務處理過程分為了投票和執行兩個階段,核心是對事務先嚐試後提交過程。

優缺點:

優點:原理簡單,實現方便。

缺點:每一階段都存在同步阻塞、協調者單點問題、保守的容錯機制(有一個結點宕機就失敗)、腦裂。

同步阻塞:二階段提交協議最明顯也是最大問題,極大限制了分散式系統性能。各個參與者在等待其餘參與者響應過程中沒法進行其他任何操作。

單點問題:協調者一旦出現問題(比如宕機),那麼整個系統都將不可用。

資料不一致(腦裂):在階段二,如果協調者發出了一部分commit訊號之後宕機,導致最終只有部分參與者收到了commit訊號。於是收到了commit訊號的參與者執行提交操作,沒有收到commit訊號的就無法提交,這兩部分節點就會出現資料不一致。(腦裂)

太過保守的容錯機制:參與者中任何一臺機器宕機都會導致整個事務的失敗。

2 . 3PC-三階段提交協議

三階段分為:1 . CanCommit、
2 . PreCommit、
3 . do commit。

協議涉及如下圖:
3PC

階段一:CanCommit(判斷各個參與者是否是alive的)

1 . 事務詢問:協調者向所有參與者傳送一個包含事務內容的canCommit請求,詢問是否可以執行事務提交操作,並等待參與者響應。

2 . 各參與者向協調者反饋事務詢問響應:參與者收到canCommit請求後,一般情況認為自身可以執行並預設返回yes,否則返回No。 這階段有點像檢測參與者是否是 alive 的。

階段二:PreCommit

根據階段一的反饋結果執行 PreCommit 或則是 中斷事務

執行事務預提交(階段一通過)

1 . 傳送預提交請求:協調者傳送PreCommit請求給各參與者,並進入Prepared階段

2 . 事務預提交:參與者收到PreCommit之後執行事務操作,並將Undo 和 Redo 資訊寫入事務日誌中。(有點類似二階段提交的投票階段)

3 . 參與者反饋響應結果給協調者:參與者成功執行了事務操作就反饋ACK訊號給協調者。參與者最後等待commit訊號或則abort訊號。

中斷事務(階段一不通過)

如果CanCommit階段任何一個參與者反饋了NO響應,或則協調者等待超時之後,那麼協調者就會發送abort訊號。

1 . 傳送中斷請求

2 . 中斷事務

階段三:Do Commit(提交事務)

這個階段是真正的事務提交過程。有兩種情況:階段二PreCommit通過,或則是階段二PreCommit有參與者返回了NO訊號。

執行事務提交(階段二通過)

1 . 傳送提交請求:協調者向所有參與者傳送do commit訊號

2 . 事務提交:參與者收到doCommit之後執行事務提交過程。

3 . 反饋提交結果:參與者返回提交結果ACK訊號給協調者。

4 . 完成事務:協調者收到ACK訊號表示事務完成。

中斷事務

如果出現:任何一個參與者在PreCommit階段返回NO訊號;或則協調者等待超時之後,參與者仍然沒有接收到所有參與者的反饋資訊;這是就會中斷事務回滾。

1 . 傳送中斷請求:協調者向所有參與者傳送 abort 請求。

2 . 參與者收到 abort 請求之後利用再階段二保留的 Undo 資訊執行事務回滾。

3 . 參與者完成回滾之後反饋回滾結果ACK訊號給協調者。

4 . 協調者收到所有參與者的反饋ACK訊號之後,完成事務中斷。

Attention:

進入階段三之後,可能存在一下兩種故障:

1)協調者宕機

2)協調者與參與者之間網路故障

只對這兩種情況,都會導致參與者無法及時接受到協調者的doCommit訊號或則abort訊號。 參與者在等待超時之後都會預設執行 commit 操作

優缺點:

優點:對比二階段協議,三階段協議降低了同步阻塞範圍。

缺點:降低了參與者的阻塞範圍但是也引入新的問題:參與者在接收到PreCommit訊號之後,如果出現網路故障,協調者與參與者無法通訊,參與者在超時之後仍然會執行事務提交,這必然會帶來資料一致性。

二階段和三階段來說:有點類似於把二階段的投票階段分為了三階段的階段一和階段二。