分佈式協議
分佈式理論概念
1. 分佈式數據一致性
分佈式數據一致性，指的是數據在多個副本中存儲時，各副本中的數據是一致的。
在分佈式系統中，數據往往有多個副本。多個副本就需要保證數據的一致性。這就帶來了同步的問題，因爲網絡延遲等因素，我們幾乎沒有辦法保證可以同時更新所有機器中的所有數據，一定會有一刻會出現數據不一致。
那麼實際應用中，我們如何既保證數據一致性，同時又不影響系統運行的性能呢？於是一致性級別的概念由此誕生。
2. 一致性級別
- 強一致性
它要求系統寫入什麼，讀出來的也會是什麼，用戶體驗好，但是實現起來對系統的性能影響比較大
- 弱一致性
這種級別，不承諾立即可以讀到寫入的值，也不承諾多久之後數據能夠達到一致，但會盡可能的保證到某個時間節點後，數據能夠達到一致狀態。
- 最終一致性
最終一致性也是弱一致性的一種，它無法保證數據更新後，所有後續的訪問能看到最新數據，而是需要一個時間，這個時間之後可以保證一致。
如微信的2小時到賬：
3. CAP理論
CAP定理，它指出一個分佈式系統不可能同時滿足以下三點：
- 一致性 （Consistency）所有節點訪問時都是同一份最新的數據副本
- 可用性（Availability）每次請求都能獲取到非異常的響應，但不保證數據最新
- 分區容錯性（Partition tolerance）分佈式系統遇到任何網絡分區故障的時候，仍然能夠對外提供服務，除非整個網絡環境都發生了故障
4. BASE理論
BASE全稱是：Basically Available（基本可用），Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫。
Base理論的核心思想是：既然無法做強一致性，那麼每個應用可以根據自身業務特定，採用適當的方式使系統達到最終一致性。
-
基本可用：出現了不可預知的故障，但還是能用。只是相對正常系統來說可能響應變慢，部分功能缺失。
-
軟狀態：指系統的數據存在中間狀態，並認爲該狀態不會影響系統的整體可用性。即允許不同副本的數據存在延遲
-
最終一致性：上面說的軟狀態，不能一直是軟狀態，必須要有時間期限。在期限過後，應當保證所有副本數據一致
分佈式一致性協議
1. 兩階段提交
兩階段提交協議，簡稱2PC（2 Prepare Commit）,是比較常用的解決分佈式事務問題的方式，要麼所有參與進程提交事務，要麼都取消事務。
階段一：事務詢問。協調者向所有資源發送事務的內容，參與者執行事務並響應結果給協調者。
階段二：協調者根據上一階段的結果，向所有參與者發送提交或回滾請求
優缺點
優點：原理簡單
缺點：
- 同步阻塞：在二階段提交的執行過程中，所有參與該事務操作的邏輯都處於阻塞狀態。
- 單點問題：當協調者出現問題，那麼整個二階段提交都無法運轉
- 數據不一致：在階段二中，執行事務提交時，如果因爲局部網絡問題導致尚未向所有的參與者發送完Commit請求就宕機的話，就會導致出現數據不一致的現象。
2. 三階段提交
三階段提交是二階段提交的改進版，將2PC的”提交事務請求“過程一分爲二，共形成了由CanCommit，PreCommit和doCommit三個階段組成的事務處理協議。
第一階段（CanCommit階段）：類似於2PC的準備（第一）階段。協調者向參與者發送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
第二階段（PreCommit階段)：協調者根據參與者的反應情況來決定是否可以執行事務的PreCommit操作。
- 如果是YES，向參與者發送預提交請求，通知參與者執行事務操作。
- 如果是NO，向參與者發送abort請求
第三階段（doCommit階段）：根據上一階段的結果進行真正的事務提交或中斷。
如果第三階段中，協調者掛掉或者協調者和參與者出現網絡問題：參與者都會在等待超時之後，繼續進行事務提交
2PC和3PC的對比：
- 3PC對於協調者和參與者都設置了超時機制（在2PC中，只有協調者擁有超時機制，即如果在一定時間內沒有收到參與者的消息則默認失敗）,主要是避免了參與者在長時間無法與協調者節點通訊（協調者掛掉了）的情況下，無法釋放資源的問題，因爲參與者自身擁有超時機制會在超時後，自動進行本地commit從而進行釋放資源。而這種機制也側面降低了整個事務的阻塞時間和範圍。
- 通過CanCommit、PreCommit、DoCommit三個階段的設計，相較於2PC而言，多設置了一個緩衝階段保證了在最後提交階段之前各參與節點的狀態是一致的 。
- PreCommit是一個緩衝，保證了在最後提交階段之前各參與節點的狀態是一致的。
3. NWR協議
NWR是一種在分佈式存儲系統中控制一致性級別的一種策略。
- N：在分佈式存儲系統中，有多少份備份數據
- W：代表一次成功的更新操作要求至少有W份數據寫入成功
- R：代表一次成功的讀數據操作要求至少有R份數據成功讀取
NWR值的不同組合會產生不同的一致性效果，當W+R>N時，整個系統對於客戶端來講能保證強一致性。而W+R<N時無法保證。
舉例：W=2 R=2 N=3
上述例子W+R>N，這種情況下，Read和Writer肯定會在某個或多個節點有交集，重合就表示強一致性。
4. Gossip 協議
Gossip協議也叫Epidemic協議（流行病協議）。原本用於分佈式數據庫中節點同步數據使用，後被廣泛用於數據庫複製、信息擴散、集羣成員身份確認、故障探測等。
gossip 協議利用一種隨機的方式將信息傳播到整個網絡中，並在一定時間內使得系統內的所有節點數據一致。Gossip 其實是一種去中心化思路的分佈式協議，解決狀態在集羣中的傳播和狀態一致性的保證兩個問題
Gossip原理
Gossip 協議的消息傳播方式有兩種：反熵傳播 和 謠言傳播
- 反熵傳播
是以固定的概率傳播所有的數據。所有參與節點只有兩種狀態：Suspective(病原)、Infective(感染)
- 謠言傳播
是以固定的概率僅傳播新到達的數據。所有參與節點有三種狀態：Suspective(病原)、Infective(感染)、Removed(愈除)。過程是消息只包含最新update，謠言消息在某個時間點之後會被標記爲 removed，並且不再被傳播
三種通信方式：推送模式、拉取模式、推/拉模式
優缺點：
綜上所述，我們可以得出Gossip是一種去中心化的分佈式協議，數據通過節點像病毒一樣逐個傳播。因爲是指數級傳播，整體傳播速度非常快。
- 優點
- 擴展性：允許節點的任意增加和減少，新增節點的狀態最終會與其他節點一致
- 容錯：任意節點的宕機和重啓都不會影響Gossip消息的傳播，具有天然的分佈式系統容錯特性
- 去中心化：無需中心節點，所有節點都是對等的，任意節點無需知道整個網絡狀況，只要網絡連通，任意節點可把消息散播到全網
- 最終一致性：Gossip協議實現信息指數級的快速傳播，因此在有新信息需要傳播時，消息可以快速地發送到全局節點，在有限的時間內能夠做到所有節點都擁有最新的數據。
- 缺點
- 消息延遲:節點隨機向少數幾個節點發送消息，消息最終是通過多個輪次的散播而到達全網；不可避免的造成消息延遲。
- 消息冗餘:節點定期隨機選擇周圍節點發送消息，而收到消息的節點也會重複該步驟；不可避免的引起同一節點消息多次接收，增加消息處理壓力
5. Paxos協議
Paxos協議其實說的就是Paxos算法。Paxos算法是基於消息傳遞且具有高度容錯特性的一致性算法，是目前公認的解決分佈式一致性問題最有效的算法之一。
自Paxos問世以來就持續壟斷了分佈式一致性算法。開源的ZooKeeper，以及MySQL 5.7推出的用來取代傳統的主從複製的MySQL Group Replication等紛紛採用Paxos算法解決分佈式一致性問題。然而，Paxos的最大特點就是難，不僅難以理解，更難以實現.
Paxos解決了什麼問題？
在常見的分佈式系統中，總會發生諸如機器宕機或網絡異常（包括消息的延遲、丟失、重複、亂序，還有網絡分區）等情況。Paxos算法需要解決的問題就是如何在一個可能發生上述異常的分佈式系統中，快速且正確地在集羣內部對某個數據的值達成一致，並且保證不論發生以上任何異常，都不會破壞整個系統的一致性
Paxos的版本有Basic Paxos，Multi Paxos，Fast-Paxos，具體落地有Raft和zk的ZAB協議。
Basic Paxos
角色概念：
- Client：客戶端
- Proposer：提案發起者。提案者提倡客戶端請求，試圖說服Accptor對此達成一致
- Acceptor：決策者，可以批准提案
- Learner：最終決策的學習者，學習者充當該協議的複製因素（不參與投票）
Basic Paxos流程圖
- 客戶端發起一個請求，它的值爲1
- Proposer發起一個提案，編號爲1
- Acceptor收到的提案編號比本地的大，就通過
- Proposer就將客戶端的值和提案一起再發給Acceptor
- Acceptor接收後複製給Learners
異常情況下：
- 如果Acceptor中有一個發生了故障，但是隻要大多數是正常的，Basic Paxos協議仍然成功
- Proposer傳遞給Acceptor的時候故障了的話，這時需要選出新的Proposer
- 如果多個提議者發生衝突了，那麼也是重新提議。
6. Raft協議
Paxos協議的出現爲分佈式強一致性提供了很好的理論基礎。但是實現比較複雜。然後斯坦福大學RamCloud項目中提出了易實現，易理解的分佈式一致性複製協議Raft。Java，C++，Go 等都有其對應的實現。
Raft協議，引入主節點，通過競選確認主節點。節點類型有Follower、Candidate、Leader。
Raft相關概念：
- 節點狀態：
- Leader（主節點） ：接受client更新請求，寫入本地後，同步給其他副本
- Follower（從節點）：從Leader中接受更新請求，然後寫入本地日誌文件。對客戶端提供讀請求
- Candidate（候選節點）：如果follower在一段時間內未收到leader心跳，則判斷leader可能故障，發起選主提議。節點狀態就會從follower變成Candidate狀態，直到選主結束
- termId：任期號，時間被劃分爲一個個任期，每次選舉後會產生一個新的termId
- RequestVote：請求投票，candidate在選舉過程中發起，收到多數派響應後，成爲leader。
Leader 會週期性的發送心跳包給Follower。每個Follower都設置了一個隨機的競選超時時間，一般爲 150ms~300ms，如果在這個時間內沒有收到 Leader 的心跳包，就會變成Candidate，進入競選階段,通過競選階段的投票多的人成爲Leader
競選階段流程
這個是Raft完整版http://thesecretlivesofdata.com/raft/動畫演示
github也提供一個https://raft.github.io/動畫演示地址 .
- 初始階段下所有節點都是follower節點，每個follower節點都會等待一個隨機的競選超時時間，如果超時時間後，沒收到Leader發來的心跳包，就會進入競選階段
- 如果節點A的隨機超時時間最短，那麼它先進入競選階段。節點A會發送投票請求給其他所有節點
- 其他節點會對投票請求進行回覆，如果超一半的節點回復了，那麼該Candidate就會變成Leader
- 之後Leader會週期性的發送心跳給Follower，Follower收到心跳後，會重新開始計時
如果多個Follower成爲Candidate並且票數相同，那麼就需要重新開始投票。當重新開始投票時，由於每個節點的隨機競選超時時間不同，因此能下一次再次出現多個Candidate並獲得相同票數的概率很低。
日誌複製
- 來自客戶端的修改會被傳入Leader，但修改還未提交，只是寫入日誌
- Leader會把修改複製到所有follower
- Leader會等待大多數的Follower也進行了修改，然後纔將修改提交
- 此時Leader會通知所有的Follower讓它們提交修改，此時所有節點的值達成一致
網絡分區
面對網絡分區，Raft也可以保持一致。
舉例說明：
當發生分區後，肯定會因爲接受不到Leader的心跳而重新發生選舉，就會出現兩個Leader。這樣就分成了2部分。
- Leader B節點+Follower A
- Leader E+Follower C+Flollwer D
原來的節點總數是5，大多數等於3.那麼客戶端往LeaderB上發的消息都是未提交的。只有發給E才能被提交。
等網絡恢復後E節點Termid較大成爲Leader節點，並同步節點數據。Leader B降爲Follower節點
7. Lease機制
Lease機制，翻譯過來是租約機制，是維護分佈式系統數據一致性的一種常用工具。
Lease機制有如下幾個特點：
- Lease是頒發者對一段時間內數據一致性的承諾
- 頒發者發出Lease後，不管是否被接受，只要Lease不過期，頒發者都會被按照協議遵守承諾
- Lease的持有者只能在Lease的有效期內使用承諾，一旦Lease超時，持有者需要放棄執行，重新申請Lease
Lease機制能解決什麼問題呢？
分佈式系統中，如何確認一個節點是否正常工作。考慮如下場景
Node1是主節點，剩下4個副本，如果Node1發生網絡抖動（Node1本身是正常的，沒有宕機），導致從節點無法接收到心跳。他們就會再選出一個主節點。
這種場景解決思路有4種：
- 設計能容忍雙主的協議
- Raft協議：通過TermId大的通過給低的
- Lease機制
- 去中心化-Gossip協議
Lease如何處理這種情況呢？
- 引入了一箇中心節點，負責下發有時效性的Lease給主節點（這個有效期內不管你出啥問題，我就認你）
- 如果網絡出現問題了，重新選了主節點。
- Lease未過期，新的主節點去申請會被拒絕
- 網絡恢復了，原來的主節點可以繼續續期
- 如果是原來的主節點是真的宕機了，那麼它的有效期過後，新的主節點就能申請成功了。
Lease時間長短一般取1-10秒。太短網絡壓力太大，太長則收回承諾的時間也長，影響可用性
Lease的容錯
- 主節點宕機 Lease的機制天生可容忍網絡、Lease接收方的出錯，時間即Lease剩餘過期時長
- 中心節點異常 中心節點異常會使得所有節點沒有Lease，解決辦法是使用小集羣作爲頒發者
- 時差問題 中心節點和主節點之間可能存在時差問題，需要校對
應用：
- GFS(Google 文件系統)中，Master通過lease機制決定哪個是主副本，lease在給各節點的心跳響應消息中攜帶。收不到心跳時，則等待lease過期，再頒發給其他節點。
- chubby中，paxos選主後，從節點會給主頒發lease，在期限內不選其他節點爲主。另一方面，主
節點給每個client節點發送lease，用於判斷client死活。