1 分散式

1.1 定義

分散式系統是一個硬體或軟體元件分佈在不同的網路計算機上，彼此之間僅僅通過訊息傳遞進行通訊和協調的系統

1.2 特點

分佈性、對等性、併發性、缺乏全域性時鐘、故障總是會發生

2 CAP 和 BASE

2.1 CAP

CAP 理論：一個分散式系統不可能同時滿足一致性、可用性和分割槽容錯性

一致性：一致性是指資料在多個副本之間是否能夠保持一致的特性

可用性：可用性是指系統提供的服務必須一直處於可用的狀態

分割槽容錯性：分散式系統在遇到任何網路分割槽故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務

2.2 BASE

Base 理論：

基本可用：分散式系統在出現不可預知故障的時候，允許損失部分可用性

弱狀態：允許系統中的資料存在中間狀態，即允許系統在不同節點的資料副本之間進行資料同步的過程存在延時

最終一致性：系統中所有的資料副本，在經過一段時間的同步後，最終能夠達到一個一直的狀態

3 一致性協議

3.1 2PC

二階段提交協議就是將事務的提交過程分成兩個階段來進行處理

3.1.1 執行流程

提交事務請求

• 1、事務詢問：協調者向所有的參與者傳送事務內容，詢問是否可以執行事務提交操作，並開始等待各參與者的響應
• 2、執行事務：各參與者節點執行事務操作，並將 Undo 和 Redo 資訊記入事務日誌中
• 3、各參與者向協調者反饋事務詢問的響應：如果參與者成執行了事務操作，那麼就反饋給協調者 YES，表示事務可以執行；反正為 NO，事務不可以執行

執行事務提交

協調者從所有的參與者獲得的反饋都是 YES

• 1、傳送提交請求：協調者向所有參與者節點發出 Commit 請求
• 2、事務提交：參與者在接收到 Commit 請求後，會正式執行事務提交操作，並在完成提交之後釋放在整個事務執行期間佔用的事務資源
• 3、反饋事務提交結果：參與者在完成事務提交後，向協調者傳送 Ack 訊息
• 4、完成事務：協調者接收到所有參與者反饋的 Ack 訊息後，完成事務

中斷事務

假設任何一個參與者向協調者反饋了 NO 請求，或者等待超時後嗎，協調者尚無法接收所有參與者的反饋響應，就會中斷事務

• 1、傳送回滾請求：協調者向所有參與者節點發送 Rollback 請求
• 2、事務回滾：參與者收到 Rollback 請求後，會利用其在階段一中記錄的 Undo 資訊來執行事務回滾操作，並在完成回滾之後釋放在這個事務執行期間佔用的資源
• 3、反饋事務回滾結果：參與者在完成事務回滾之後，向協調者傳送 Ack 訊息
• 4、中斷事務：協調者接收到所有參與者反饋的 Ack 訊息後，完成事務中斷

3.1.2 優缺點

優點：原理簡單，實現方便

缺點：

• 同步阻塞：在事務提交過程中，所以參與該事務操作的邏輯都處於阻塞狀態，無法進行其他任何操作
• 單點問題：如果協調者在事務提交階段掛掉，那麼其他參與者將一直處於鎖定事務資源的狀態，而無法繼續完成事務操作
• 資料不一致：如果協調者在傳送 Commit 請求時，出現區域性網路異常，那麼就會導致只有部分參與者收到了 Commit 請求並進行事務的提交，而其他沒有收到 Commit 請求的參與者則無法進行事務提交，於是會出現資料不一致現象
• 太過保守：沒有設計較為完善的容錯機制，任意一個節點的失敗都會導致整個事務的失敗

3.2 3PC

3.2.1 執行流程

CanCommit

• 1、事務詢問：協調者向所有參與者傳送一個包含事務內容的 canCommit 請求，詢問是否可以執行事務提交操作，並開始等待各參與者的響應
• 2、各參與者向協調者反饋事務詢問的響應：參與者在接收到來自協調者 canCommit 請求後，正常情況下，如果其自身認為可以順利執行事務，就會反饋 Yes 響應，並進入預備狀態，否則反饋 NO 響應

PreCommit

執行事務預提交

• 1、傳送預提交請求：協調者向所有參與者節點發出 preCommit 的請求，並進入 Prepared 階段
• 2、事務預提交請求：參與者接收到 preCommit 請求後，會執行事務操作，並將 Undo 和 Redo 資訊記錄到事務日誌中
• 3、各參與者向協調者反饋事務執行的響應：如果參與者成功執行了事務操作，那麼就會反饋給協調者 Ack 響應，同時等待最終的指令

中斷事務

假設任何一個參與者向協調者反饋了 No 響應，或者在等待超時之後，協調者尚無法接收到所有參與者的反饋響應，就會中斷事務

• 1、傳送中斷請求：協調者向所有參與者節點發送 abort 請求
• 2、中斷事務：參與者中斷事務

doCommit

執行提交

• 1、傳送提交請求：協調者收到所有參與者的 Ack 的響應後，會向所有參與者傳送 doCommit 請求
• 2、事務提交：參與者接收到 doCommit 請求後，會正式執行事務提交操作，並在完成提交之後釋放在整個事務執行期間佔用的事務資源
• 3、反饋事務提交結果：參與者在完成事務提交後，向協調者傳送 Ack 訊息
• 4、完成事務：協調者接收到所有參與者反饋的 Ack 訊息後，完成事務

中斷事務

任何一個參與者向協調者傳送 NO 反饋，或者協調者無法接收到所有參與者的反饋響應

• 1、傳送中斷請求：協調者向所有參與者節點發送 abort 請求
• 2、事務回滾：參與者接收到 abort 請求後，會利用其記錄的 Undo 資訊來執行事務回滾操作，並在完成回滾之後釋放佔用的資源
• 3、反饋事務回滾結果：參與者在完成事務回滾之後，向協調者傳送 Ack 訊息
• 4、中斷事務

3.2.2 優缺點

優點：降低了參與者的阻塞範圍，並且能夠在出現單點故障後繼續達成一致

缺點：參與者接收到 preCommit 訊息後，如果網路出現分割槽，此時協調者所在的節點和參與者無法進行正常的網路通訊，這種情況下，該參與者依然會進行事務的提交，這必然出現數據的不一致性

3.3 PAXOS

Paxos 一致性演算法中，有三種參與角色，Proposer（生成提案），Acceptor（批准提案），Learner

提案選定

階段一

• 1、Proposer 選擇一個提案編號 Mn，然後向 Acceptor 的某個超過半數的子整合員傳送編號為 Mn 的 Prepare 請求
• 如果一個 Acceptor 收到一個編號為 Mn 的 Prepare 請求，且編號 Mn 大於該 Acceptor 已經響應的所有 Prepare 請求的編號，那麼它就會將它已經批准過的最大編號的提案作為響應反饋給 Proposer，同時該 Acceptor 會承諾不再批准任何編號小於 Mn 的提案。舉個例子來說，假定一個 Acceptor 已經響應過的所有 Prepare 請求對應的提案編號分別為 1、2、3…、5 和 7，那麼該 Acceptor 在接收到一個編號為 8 的prepare 請求後，就會將編號 7 的提案作為響應反饋給 Proposer

階段二

• 1、如果 Proposer 收到來自半數以上的 Acceptor 對於其發出的編號為 Mn 的 Prepare 請求的響應，那麼它就會發送一個針對 [Mn,Vn] 提案的 Accept 請求給 Acceptor。注意，Vn 的值就是收到的響應中編號最大的提案的值，如果響應中不包含任何提案，那麼它就是任意值
• 2、如果 Acceptor 收到針對 [Mn,Vn] 提案的 Accept 請求，只要該 Acceptor 尚未對編號大於 Mn 的 Prepare 請求做出響應，它就可以通過這個提案

提案獲取

Acceptor 可以將批准的提案發送給一個特定的 Learner 集合，該集合中的每個 Learner 都可以在一個提案被選定後通知所有其他的 Learner

文章來源：https://gongfukangee.github.io/2018/10/02/Zookeeper-1/