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該次事務
Paxos算法
Paxos算法是萊斯利·蘭伯特（英語：Leslie Lamport，LaTeX中的“La”）於1990年提出的一種基於消息傳遞且具有高度容錯特性的一致性算法。
Google Chubby的作者Mike Burrows說過這個世界上只有一種一致性算法，那就是Paxos，其它的算法都是殘次品。
基於拜占庭將軍問題解析：
分爲以下兩種角色：
proposer：參謀1，參謀2（提交者）
acceptor： 將軍1，將軍2，將軍3（決策者）
1、先後提議的場景
參謀1發起提議，派通信兵帶信給3個將軍，內容爲（編號1）
3個將軍收到參謀1的提議，由於之前還沒有保存任何編號，因此把（編號1）保存下來，避免遺忘；同時讓通信兵帶信回去，內容爲（ok）
參謀1收到至少2個將軍的回覆，再次派通信兵帶信給3個將軍，內容爲（編號1，進攻時間1）
3個將軍收到參謀1的時間，把（編號1，進攻時間1）保存下來，避免遺忘；同時讓通信兵帶信回去，內容爲（Accepted）
參謀1收到至少2個將軍的（Accepted）內容，確認進攻時間已經被大家接收；
參謀2發起提議，派通信兵帶信給3個將軍，內容爲（編號2）
3個將軍收到參謀2的提議，由於（編號2）比（編號1）大，因此把（編號2）保存下來，避免遺忘；又由於之前已經接受參謀1的提議，因此讓通信兵帶信回去，內容爲（編號1，進攻時間1）
參謀2收到至少2個將軍的回覆，由於回覆中帶來了已接受的參謀1的提議內容，參謀2因此不再提出新的進攻時間，接受參謀1提出的時間
2、交叉提交場景
1.參謀1發起提議，派通信兵帶信給3個將軍，內容爲（編號1）；
2.3個將軍的情況如下
a）將軍1和將軍2收到參謀1的提議，將軍1和將軍2把（編號1）記錄下來，如果有其他參謀提出更小的編號，將被拒絕；同時讓通信兵帶信回去，內容爲（ok）
b）負責通知將軍3的通信兵被抓，因此將軍3沒收到參謀1的提議
3.參謀2在同一時間也發起了提議，派通信兵帶信給3個將軍，內容爲（編號2）
4.3個將軍的情況如下
a）將軍2和將軍3收到參謀2的提議，將軍2和將軍3把（編號2）記錄下來，如果有其他參謀提出更小的編號，將被拒絕；同時讓通信兵帶信回去，內容爲（ok）
b）負責通知將軍1的通信兵被抓，因此將軍1沒收到參謀2的提議
5.參謀1收到至少2個將軍的回覆，再次派通信兵帶信給有答覆的2個將軍，內容爲（編號1，進攻時間1）
6.2個將軍的情況如下
a）將軍1收到了（編號1，進攻時間1），和自己保存的編號相同，因此把（編號1，進攻時間1）保存下來；同時讓通信兵帶信回去，內容爲（Accepted）
b）將軍2收到了（編號1，進攻時間1），由於（編號1）小於已經保存的（編號2），因此讓通信兵帶信回去，內容爲（Rejected，編號2）
7.參謀2收到至少2個將軍的回覆，再次派通信兵帶信給有答覆的2個將軍，內容爲（編號2，進攻時間2）
8.將軍2和將軍3收到了（編號2，進攻時間2），和自己保存的編號相同，因此把（編號2，進攻時間2）保存下來，同時讓通信兵帶信回去，內容爲（Accepted）
9.參謀2收到至少2個將軍的（Accepted）內容，確認進攻時間已經被多數派接受
10.參謀1只收到了1個將軍的（Accepted）內容，同時收到一個（Rejected，編號2）
參謀1重新發起提議，派通信兵帶信給3個將軍，內容爲（編號3）
11.3個將軍的情況如下
a）將軍1收到參謀1的提議，由於（編號3）大於之前保存的（編號1），因此把（編號3）保存下來；由於將軍1已經接受參謀1前一次的提議，因此讓通信兵帶信回去，內容爲（編號1，進攻時間1）
b）將軍2收到參謀1的提議，由於（編號3）大於之前保存的（編號2），因此把（編號3）保存下來；由於將軍2已經接受參謀2的提議，因此讓通信兵帶信回去，內容爲（編號2，進攻時間2）
c）負責通知將軍3的通信兵被抓，因此將軍3沒收到參謀1的提議
12.參謀1收到了至少2個將軍的回覆，比較兩個回覆的編號大小，選擇大編號對應的進攻時間作爲最新的提議；參謀1再次派通信兵帶信給有答覆的2個將軍，內容爲（編號3，進攻時間2）
13.將軍1和將軍2收到了（編號3，進攻時間2），和自己保存的編號相同，因此保存（編號3，進攻時間2），同時讓通信兵帶信回去，內容爲（Accepted）
14.參謀1收到了至少2個將軍的（accepted）內容，確認進攻時間已經被多數派接受。