1，一致性協議
兩階段提交協議與Raft協議、Paxos協議
①兩階段提交協議
在分佈式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，爲了保持事務的ACID特性，需要引入一個作爲協調者的組件來統一掌控所有節點(稱作參與者)的操作結果並最終指示這些節點是否要把操作結果進行真正的提交(比如將更新後的數據寫入磁盤等等)。因此，二階段提交的算法思路可以概括爲： 參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。
因此，系統包含兩類節點，一類是協調者，一類是參與者，協議的執行由兩個階段組成：
具體參考：二階段提交：維基百科
兩階段協議是阻塞的，節點在等待對方的應答消息時，它不能做其他事情且持有的資源也不釋放。它主要是用來保證跨多個節點的操作的原子性--要麼都操作，要麼都不操作，而像Raft協議則諸如用來保證操作的一致性，即各個節點都執行相同的操作。
兩階段協議的舉例參考：兩階段提交協議
②Raft協議和Paxos協議
Raft與Paxos 在分佈式應用中的基本功能相似，但是Paxos難於理解，相對而言Raft算法要簡單一些。關於Raft協議有一篇經典的論文：
《In Search of an Understandable Consensus Algorithm (Extended Version)》
其中文翻譯地址參考：尋找一種易於理解的一致性算法（擴展版）
還有一篇文章詳細解釋了Raft算法的相關實現：Raft論文的第 31 號參考文獻。
下面僅記錄一下看論文過程中出現的一個問題：
爲什麼 “大多數規則” 能夠保證對於一個給定的任期，只會有一個候選人最終贏得選舉成爲Leader？
在Raft中，對於一個給定的任期號，每一臺Server按照先來先服務原則對該任期號最多隻投一張票，若某Candidate發送的請求投票RPC帶有的任期號獲得超過半數的Server的同意，則該Candidate成爲Leader。
正是由於每個Server對某個任期只最多投一次票，且獲得的投票要超過半數才能成爲Leader，故在一個給定的任期投票中，最終只會有一個Candidate成爲Leader。
關於Raft協議中的Leader選舉步驟參考：Raft系列文章之二：Leader選舉
2，分佈式系統中常見的三種一致性模型
①強一致性：當更新操作在某個副本上執行成功後，之後所有的讀操作都要能夠獲得最新的數據。對於單副本而言，讀寫操作都是在同一數據上執行，很容易保證一致性；而對於多副本數據，則需要使用分佈式協議如2PC協議。
②弱一致性：當更新某數據時，用戶讀到最新的數據需要一段時間。
③最終一致性：它是一種特殊形式的弱一致性。它不能保證當某個數據Ｘ更新後，在所有後續對Ｘ的操作能夠看到新數據，而是需要一個時間片段，在經過該時間片段之後，則能保證。在這個時間片段內，數據可能是不一致的，該片段稱“不一致窗口“。
參考：數據一致性模型
3，拜占庭將軍問題
在分佈式理論中，經常看到”在非拜占庭錯誤情況下，算法是有效的……“ 或者說 ”...可以容忍非拜占庭失效“。那麼什麼是拜占庭將軍問題呢？
在分佈式計算上，不同的計算機透過訊息交換，嘗試達成共識；但有時候，系統上協調計算機（Coordinator / Commander）或成員計算機 （Member / Lieutanent）可能因系統錯誤並交換錯的訊息，導致影響最終的系統一致性。參考：維基百科：拜占庭將軍問題
也即，在系統不同的機器之間會傳遞錯誤的消息，這種情況即爲拜占庭問題。這與”網絡分割、機器崩潰...”是不同的。比如Raft協議不能容忍拜占庭問題，但是能夠 在非拜占庭錯誤情況下，有網絡延遲、分區、丟包、冗餘和亂序等錯誤情況出現時，都可以保證其操作的正確性。
4，租約，心跳包(heartbeat)
①租約
這裏主要列舉租約可以用來幹什麼？
a,進行故障檢測。這類似於ZooKeeper中master 與 slaver 之間發送的心跳包的作用。在ZK中， master 和 slaver 之間通過交換心跳包來檢測它們是否還存活。一個具體的例子參考：故障檢測
b,維護緩存一致性維護緩存的一致性，第一種辦法是輪詢：每次讀取數據時都先詢問服務器數據是不是最新的，若不是，則先讓服務器傳輸新數據，然後再讀取該新數據。第二種方法是回調：由服務器記錄有哪些客戶端讀取了數據，當服務器對數據做修改時先通知記錄下來的這些客戶端，上次讀取過的數據已經失效。這二種方法都有一定的缺陷，參考：租約機制簡介
因此，可以引入租約機制。在租約期限內，可以保證客戶端緩存的數據是最新的。當租約過期後，客戶端需要重新向服務器詢問數據，重新續約。
租約的定義：租約就是在一定期限內給予持有者特定權力的 協議。每個租約都有一個期限，正是這個期限可以保證租約機制容忍機器失效和網絡分割。
租約機制優化後臺數據庫訪問的一個例子：使用租約機制解決緩存數據更新的問題
5，副本協議
副本協議是控制副本讀寫行爲的規則，使得副本滿足可用性和一致性。
副本協議分爲兩類，①中心化的副本控制協議：由一箇中心節點協調副本數據的更新，維護副本數據的一致性。這裏重點介紹下常用的Primary-Secondary中心化副本控制協議：假設數據是以數據段(segment/partition)爲單位分佈在集羣各臺機器上的，每個數據段指定一個作爲主副本，其餘的數據段則爲從副本，對該數據段的更新（讀寫）而言，由主副本來負責。比如，當多個Client同時需要更新某個數據段時，所有的更新操作都發送到該數據段所對應的主副本所在的機器上，由它來確定更新的順序，負責協調一致性。
那麼，Client如何找到主副本所在的機器呢？？？這需要一個元數據服務器，它專門用來記錄主副本的位置及相關信息，記錄集羣個各個數據段的主副本的位置信息，副本分配情況……該元數據服務器應該相當於GFS中的Master。
注意：由於上面是假設數據不是以機器爲單位分佈在集羣中，而是以數據段爲單位分佈在集羣中，當某個數據段被指定爲主副本時，該主副本也是按照以數據段爲單位的數據分佈方式分佈到集羣中的，即各個Primary副本的位置在集羣中是隨機分配的。
要將Primary副本所在的機器與Master機器區分開來：應該在GFS中，Primary副本所在的機器可能是某臺Slaver機器，它用來存儲各個數據塊。而Master是用來存儲元數據信息的。
②去中心化的副本控制協議：各個節點之間是平等的，通過協商方式來達成某些操作。
學習材料參考：《分佈式系統原理介紹 劉傑》