分布式概念与协议
Python微信訂餐小程序課程視頻
https://edu.csdn.net/course/detail/36074
Python實戰量化交易理財系統
https://edu.csdn.net/course/detail/35475
分布式協議
分布式理論概念
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的對比:
3. NWR協議
NWR是一種在分布式存儲系統中控制一致性級別的一種策略。
- N:在分布式存儲系統中,有多少份備份數據
- W:代表一次成功的更新操作要求至少有W份數據寫入成功
- R:代表一次成功的讀數據操作要求至少有R份數據成功讀取
NWR值的不同組合會產生不同的一致性效果,當W+R>N時,整個系統對于客戶端來講能保證強一致性。而W+R
舉例: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流程圖
異常情況下:
6. Raft協議
Paxos協議的出現為分布式強一致性提供了很好的理論基礎。但是實現比較復雜。然后斯坦福大學RamCloud項目中提出了易實現,易理解的分布式一致性復制協議Raft。Java,C++,Go 等都有其對應的實現。
Raft協議,引入主節點,通過競選確認主節點。節點類型有Follower、Candidate、Leader。
Raft相關概念:
- Leader(主節點) :接受client更新請求,寫入本地后,同步給其他副本
- Follower(從節點):從Leader中接受更新請求,然后寫入本地日志文件。對客戶端提供讀請求
- Candidate(候選節點):如果follower在一段時間內未收到leader心跳,則判斷leader可能故障,發起選主提議。節點狀態就會從follower變成Candidate狀態,直到選主結束
Leader 會周期性的發送心跳包給Follower。每個Follower都設置了一個隨機的競選超時時間,一般為 150ms~300ms,如果在這個時間內沒有收到 Leader 的心跳包,就會變成Candidate,進入競選階段,通過競選階段的投票多的人成為Leader
競選階段流程
這個是Raft完整版http://thesecretlivesofdata.com/raft/動畫演示
github也提供一個https://raft.github.io/動畫演示地址 .
如果多個Follower成為Candidate并且票數相同,那么就需要重新開始投票。當重新開始投票時,由于每個節點的隨機競選超時時間不同,因此能下一次再次出現多個Candidate并獲得相同票數的概率很低。
日志復制
網絡分區
面對網絡分區,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時間長短一般取1-10秒。太短網絡壓力太大,太長則收回承諾的時間也長,影響可用性
Lease的容錯
應用:
節點給每個client節點發送lease,用于判斷client死活。
總結
- 上一篇: ANT简明教程[转载]
- 下一篇: 有哪些好看的字体可以免费用?看完这篇就知