Python微信訂餐小程序課程視頻

https://edu.csdn.net/course/detail/36074

Python實(shí)戰(zhàn)量化交易理財(cái)系統(tǒng)

https://edu.csdn.net/course/detail/35475

分布式協(xié)議

分布式理論概念

1. 分布式數(shù)據(jù)一致性

分布式數(shù)據(jù)一致性，指的是數(shù)據(jù)在多個(gè)副本中存儲時(shí)，各副本中的數(shù)據(jù)是一致的。

在分布式系統(tǒng)中，數(shù)據(jù)往往有多個(gè)副本。多個(gè)副本就需要保證數(shù)據(jù)的一致性。這就帶來了同步的問題，因?yàn)榫W(wǎng)絡(luò)延遲等因素，我們幾乎沒有辦法保證可以同時(shí)更新所有機(jī)器中的所有數(shù)據(jù)，一定會有一刻會出現(xiàn)數(shù)據(jù)不一致。

那么實(shí)際應(yīng)用中，我們?nèi)绾渭缺ＷC數(shù)據(jù)一致性，同時(shí)又不影響系統(tǒng)運(yùn)行的性能呢？于是一致性級別的概念由此誕生。

2. 一致性級別

強(qiáng)一致性

它要求系統(tǒng)寫入什么，讀出來的也會是什么，用戶體驗(yàn)好，但是實(shí)現(xiàn)起來對系統(tǒng)的性能影響比較大

弱一致性

這種級別，不承諾立即可以讀到寫入的值，也不承諾多久之后數(shù)據(jù)能夠達(dá)到一致，但會盡可能的保證到某個(gè)時(shí)間節(jié)點(diǎn)后，數(shù)據(jù)能夠達(dá)到一致狀態(tài)。

最終一致性

最終一致性也是弱一致性的一種，它無法保證數(shù)據(jù)更新后，所有后續(xù)的訪問能看到最新數(shù)據(jù)，而是需要一個(gè)時(shí)間，這個(gè)時(shí)間之后可以保證一致。

如微信的2小時(shí)到賬：

3. CAP理論

CAP定理，它指出一個(gè)分布式系統(tǒng)不可能同時(shí)滿足以下三點(diǎn)：

• 一致性 （Consistency）所有節(jié)點(diǎn)訪問時(shí)都是同一份最新的數(shù)據(jù)副本
• 可用性（Availability）每次請求都能獲取到非異常的響應(yīng)，但不保證數(shù)據(jù)最新
• 分區(qū)容錯(cuò)性（Partition tolerance）分布式系統(tǒng)遇到任何網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然能夠?qū)ν馓峁┓?wù)，除非整個(gè)網(wǎng)絡(luò)環(huán)境都發(fā)生了故障

4. BASE理論

BASE全稱是：Basically Available（基本可用），Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）三個(gè)短語的縮寫。

Base理論的核心思想是：既然無法做強(qiáng)一致性，那么每個(gè)應(yīng)用可以根據(jù)自身業(yè)務(wù)特定，采用適當(dāng)?shù)姆绞绞瓜到y(tǒng)達(dá)到最終一致性。

• 基本可用：出現(xiàn)了不可預(yù)知的故障，但還是能用。只是相對正常系統(tǒng)來說可能響應(yīng)變慢，部分功能缺失。
• 軟狀態(tài)：指系統(tǒng)的數(shù)據(jù)存在中間狀態(tài)，并認(rèn)為該狀態(tài)不會影響系統(tǒng)的整體可用性。即允許不同副本的數(shù)據(jù)存在延遲
• 最終一致性：上面說的軟狀態(tài)，不能一直是軟狀態(tài)，必須要有時(shí)間期限。在期限過后，應(yīng)當(dāng)保證所有副本數(shù)據(jù)一致

分布式一致性協(xié)議

1. 兩階段提交

兩階段提交協(xié)議，簡稱2PC（2 Prepare Commit）,是比較常用的解決分布式事務(wù)問題的方式，要么所有參與進(jìn)程提交事務(wù)，要么都取消事務(wù)。

階段一：事務(wù)詢問。協(xié)調(diào)者向所有資源發(fā)送事務(wù)的內(nèi)容，參與者執(zhí)行事務(wù)并響應(yīng)結(jié)果給協(xié)調(diào)者。

階段二：協(xié)調(diào)者根據(jù)上一階段的結(jié)果，向所有參與者發(fā)送提交或回滾請求

優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：原理簡單

缺點(diǎn)：

• 同步阻塞：在二階段提交的執(zhí)行過程中，所有參與該事務(wù)操作的邏輯都處于阻塞狀態(tài)。
• 單點(diǎn)問題：當(dāng)協(xié)調(diào)者出現(xiàn)問題，那么整個(gè)二階段提交都無法運(yùn)轉(zhuǎn)
• 數(shù)據(jù)不一致：在階段二中，執(zhí)行事務(wù)提交時(shí)，如果因?yàn)榫植烤W(wǎng)絡(luò)問題導(dǎo)致尚未向所有的參與者發(fā)送完Commit請求就宕機(jī)的話，就會導(dǎo)致出現(xiàn)數(shù)據(jù)不一致的現(xiàn)象。

2. 三階段提交

三階段提交是二階段提交的改進(jìn)版，將2PC的”提交事務(wù)請求“過程一分為二，共形成了由CanCommit，PreCommit和doCommit三個(gè)階段組成的事務(wù)處理協(xié)議。

第一階段（CanCommit階段）：類似于2PC的準(zhǔn)備（第一）階段。協(xié)調(diào)者向參與者發(fā)送commit請求，參與者如果可以提交就返回Yes響應(yīng)，否則返回No響應(yīng)。

第二階段（PreCommit階段)：協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以執(zhí)行事務(wù)的PreCommit操作。

• 如果是YES，向參與者發(fā)送預(yù)提交請求，通知參與者執(zhí)行事務(wù)操作。
• 如果是NO，向參與者發(fā)送abort請求

第三階段（doCommit階段）：根據(jù)上一階段的結(jié)果進(jìn)行真正的事務(wù)提交或中斷。

如果第三階段中，協(xié)調(diào)者掛掉或者協(xié)調(diào)者和參與者出現(xiàn)網(wǎng)絡(luò)問題：參與者都會在等待超時(shí)之后，繼續(xù)進(jìn)行事務(wù)提交

2PC和3PC的對比：

3PC對于協(xié)調(diào)者和參與者都設(shè)置了超時(shí)機(jī)制（在2PC中，只有協(xié)調(diào)者擁有超時(shí)機(jī)制，即如果在一定時(shí)間內(nèi)沒有收到參與者的消息則默認(rèn)失敗）,主要是避免了參與者在長時(shí)間無法與協(xié)調(diào)者節(jié)點(diǎn)通訊（協(xié)調(diào)者掛掉了）的情況下，無法釋放資源的問題，因?yàn)閰⑴c者自身擁有超時(shí)機(jī)制會在超時(shí)后，自動(dòng)進(jìn)行本地commit從而進(jìn)行釋放資源。而這種機(jī)制也側(cè)面降低了整個(gè)事務(wù)的阻塞時(shí)間和范圍。

通過CanCommit、PreCommit、DoCommit三個(gè)階段的設(shè)計(jì)，相較于2PC而言，多設(shè)置了一個(gè)緩沖階段保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的 。

PreCommit是一個(gè)緩沖，保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

3. NWR協(xié)議

NWR是一種在分布式存儲系統(tǒng)中控制一致性級別的一種策略。

• N：在分布式存儲系統(tǒng)中，有多少份備份數(shù)據(jù)
• W：代表一次成功的更新操作要求至少有W份數(shù)據(jù)寫入成功
• R：代表一次成功的讀數(shù)據(jù)操作要求至少有R份數(shù)據(jù)成功讀取

NWR值的不同組合會產(chǎn)生不同的一致性效果，當(dāng)W+R>N時(shí)，整個(gè)系統(tǒng)對于客戶端來講能保證強(qiáng)一致性。而W+R
舉例：W=2 R=2 N=3

上述例子W+R>N，這種情況下，Read和Writer肯定會在某個(gè)或多個(gè)節(jié)點(diǎn)有交集，重合就表示強(qiáng)一致性。

4. Gossip 協(xié)議

Gossip協(xié)議也叫Epidemic協(xié)議（流行病協(xié)議）。原本用于分布式數(shù)據(jù)庫中節(jié)點(diǎn)同步數(shù)據(jù)使用，后被廣泛用于數(shù)據(jù)庫復(fù)制、信息擴(kuò)散、集群成員身份確認(rèn)、故障探測等。

gossip 協(xié)議利用一種隨機(jī)的方式將信息傳播到整個(gè)網(wǎng)絡(luò)中，并在一定時(shí)間內(nèi)使得系統(tǒng)內(nèi)的所有節(jié)點(diǎn)數(shù)據(jù)一致。Gossip 其實(shí)是一種去中心化思路的分布式協(xié)議，解決狀態(tài)在集群中的傳播和狀態(tài)一致性的保證兩個(gè)問題

Gossip原理

Gossip 協(xié)議的消息傳播方式有兩種：反熵傳播 和 謠言傳播

• 反熵傳播

是以固定的概率傳播所有的數(shù)據(jù)。所有參與節(jié)點(diǎn)只有兩種狀態(tài)：Suspective(病原)、Infective(感染)

• 謠言傳播

是以固定的概率僅傳播新到達(dá)的數(shù)據(jù)。所有參與節(jié)點(diǎn)有三種狀態(tài)：Suspective(病原)、Infective(感染)、Removed(愈除)。過程是消息只包含最新update，謠言消息在某個(gè)時(shí)間點(diǎn)之后會被標(biāo)記為 removed，并且不再被傳播

三種通信方式：推送模式、拉取模式、推/拉模式

優(yōu)缺點(diǎn)：

綜上所述，我們可以得出Gossip是一種去中心化的分布式協(xié)議，數(shù)據(jù)通過節(jié)點(diǎn)像病毒一樣逐個(gè)傳播。因?yàn)槭侵笖?shù)級傳播，整體傳播速度非常快。

優(yōu)點(diǎn)

• 擴(kuò)展性：允許節(jié)點(diǎn)的任意增加和減少，新增節(jié)點(diǎn)的狀態(tài)最終會與其他節(jié)點(diǎn)一致
• 容錯(cuò)：任意節(jié)點(diǎn)的宕機(jī)和重啟都不會影響Gossip消息的傳播，具有天然的分布式系統(tǒng)容錯(cuò)特性
• 去中心化：無需中心節(jié)點(diǎn)，所有節(jié)點(diǎn)都是對等的，任意節(jié)點(diǎn)無需知道整個(gè)網(wǎng)絡(luò)狀況，只要網(wǎng)絡(luò)連通，任意節(jié)點(diǎn)可把消息散播到全網(wǎng)
• 最終一致性：Gossip協(xié)議實(shí)現(xiàn)信息指數(shù)級的快速傳播，因此在有新信息需要傳播時(shí)，消息可以快速地發(fā)送到全局節(jié)點(diǎn)，在有限的時(shí)間內(nèi)能夠做到所有節(jié)點(diǎn)都擁有最新的數(shù)據(jù)。

缺點(diǎn)

• 消息延遲:節(jié)點(diǎn)隨機(jī)向少數(shù)幾個(gè)節(jié)點(diǎn)發(fā)送消息，消息最終是通過多個(gè)輪次的散播而到達(dá)全網(wǎng)；不可避免的造成消息延遲。
• 消息冗余:節(jié)點(diǎn)定期隨機(jī)選擇周圍節(jié)點(diǎn)發(fā)送消息，而收到消息的節(jié)點(diǎn)也會重復(fù)該步驟；不可避免的引起同一節(jié)點(diǎn)消息多次接收，增加消息處理壓力

5. Paxos協(xié)議

Paxos協(xié)議其實(shí)說的就是Paxos算法。Paxos算法是基于消息傳遞且具有高度容錯(cuò)特性的一致性算法，是目前公認(rèn)的解決分布式一致性問題最有效的算法之一。

自Paxos問世以來就持續(xù)壟斷了分布式一致性算法。開源的ZooKeeper，以及MySQL 5.7推出的用來取代傳統(tǒng)的主從復(fù)制的MySQL Group Replication等紛紛采用Paxos算法解決分布式一致性問題。然而，Paxos的最大特點(diǎn)就是難，不僅難以理解，更難以實(shí)現(xiàn).

Paxos解決了什么問題？

在常見的分布式系統(tǒng)中，總會發(fā)生諸如機(jī)器宕機(jī)或網(wǎng)絡(luò)異常（包括消息的延遲、丟失、重復(fù)、亂序，還有網(wǎng)絡(luò)分區(qū)）等情況。Paxos算法需要解決的問題就是如何在一個(gè)可能發(fā)生上述異常的分布式系統(tǒng)中，快速且正確地在集群內(nèi)部對某個(gè)數(shù)據(jù)的值達(dá)成一致，并且保證不論發(fā)生以上任何異常，都不會破壞整個(gè)系統(tǒng)的一致性

Paxos的版本有Basic Paxos，Multi Paxos，Fast-Paxos，具體落地有Raft和zk的ZAB協(xié)議。

Basic Paxos

角色概念：

• Client：客戶端
• Proposer：提案發(fā)起者。提案者提倡客戶端請求，試圖說服Accptor對此達(dá)成一致
• Acceptor：決策者，可以批準(zhǔn)提案
• Learner：最終決策的學(xué)習(xí)者，學(xué)習(xí)者充當(dāng)該協(xié)議的復(fù)制因素（不參與投票）

Basic Paxos流程圖

客戶端發(fā)起一個(gè)請求，它的值為1

Proposer發(fā)起一個(gè)提案，編號為1

Acceptor收到的提案編號比本地的大，就通過

Proposer就將客戶端的值和提案一起再發(fā)給Acceptor

Acceptor接收后復(fù)制給Learners

異常情況下：

如果Acceptor中有一個(gè)發(fā)生了故障，但是只要大多數(shù)是正常的，Basic Paxos協(xié)議仍然成功

Proposer傳遞給Acceptor的時(shí)候故障了的話，這時(shí)需要選出新的Proposer

如果多個(gè)提議者發(fā)生沖突了，那么也是重新提議。

6. Raft協(xié)議

Paxos協(xié)議的出現(xiàn)為分布式強(qiáng)一致性提供了很好的理論基礎(chǔ)。但是實(shí)現(xiàn)比較復(fù)雜。然后斯坦福大學(xué)RamCloud項(xiàng)目中提出了易實(shí)現(xiàn)，易理解的分布式一致性復(fù)制協(xié)議Raft。Java，C++，Go 等都有其對應(yīng)的實(shí)現(xiàn)。

Raft協(xié)議，引入主節(jié)點(diǎn)，通過競選確認(rèn)主節(jié)點(diǎn)。節(jié)點(diǎn)類型有Follower、Candidate、Leader。

Raft相關(guān)概念：

節(jié)點(diǎn)狀態(tài)：

• Leader（主節(jié)點(diǎn)） ：接受client更新請求，寫入本地后，同步給其他副本
• Follower（從節(jié)點(diǎn)）：從Leader中接受更新請求，然后寫入本地日志文件。對客戶端提供讀請求
• Candidate（候選節(jié)點(diǎn)）：如果follower在一段時(shí)間內(nèi)未收到leader心跳，則判斷l(xiāng)eader可能故障，發(fā)起選主提議。節(jié)點(diǎn)狀態(tài)就會從follower變成Candidate狀態(tài)，直到選主結(jié)束

termId：任期號，時(shí)間被劃分為一個(gè)個(gè)任期，每次選舉后會產(chǎn)生一個(gè)新的termId

RequestVote：請求投票，candidate在選舉過程中發(fā)起，收到多數(shù)派響應(yīng)后，成為leader。

Leader 會周期性的發(fā)送心跳包給Follower。每個(gè)Follower都設(shè)置了一個(gè)隨機(jī)的競選超時(shí)時(shí)間，一般為 150ms~300ms，如果在這個(gè)時(shí)間內(nèi)沒有收到 Leader 的心跳包，就會變成Candidate，進(jìn)入競選階段,通過競選階段的投票多的人成為Leader

競選階段流程

這個(gè)是Raft完整版http://thesecretlivesofdata.com/raft/動(dòng)畫演示

github也提供一個(gè)https://raft.github.io/動(dòng)畫演示地址 .

初始階段下所有節(jié)點(diǎn)都是follower節(jié)點(diǎn)，每個(gè)follower節(jié)點(diǎn)都會等待一個(gè)隨機(jī)的競選超時(shí)時(shí)間，如果超時(shí)時(shí)間后，沒收到Leader發(fā)來的心跳包，就會進(jìn)入競選階段

如果節(jié)點(diǎn)A的隨機(jī)超時(shí)時(shí)間最短，那么它先進(jìn)入競選階段。節(jié)點(diǎn)A會發(fā)送投票請求給其他所有節(jié)點(diǎn)

其他節(jié)點(diǎn)會對投票請求進(jìn)行回復(fù)，如果超一半的節(jié)點(diǎn)回復(fù)了，那么該Candidate就會變成Leader

之后Leader會周期性的發(fā)送心跳給Follower，Follower收到心跳后，會重新開始計(jì)時(shí)

如果多個(gè)Follower成為Candidate并且票數(shù)相同，那么就需要重新開始投票。當(dāng)重新開始投票時(shí)，由于每個(gè)節(jié)點(diǎn)的隨機(jī)競選超時(shí)時(shí)間不同，因此能下一次再次出現(xiàn)多個(gè)Candidate并獲得相同票數(shù)的概率很低。

日志復(fù)制

來自客戶端的修改會被傳入Leader，但修改還未提交，只是寫入日志

Leader會把修改復(fù)制到所有follower

Leader會等待大多數(shù)的Follower也進(jìn)行了修改，然后才將修改提交

此時(shí)Leader會通知所有的Follower讓它們提交修改，此時(shí)所有節(jié)點(diǎn)的值達(dá)成一致

網(wǎng)絡(luò)分區(qū)

面對網(wǎng)絡(luò)分區(qū)，Raft也可以保持一致。

舉例說明：

當(dāng)發(fā)生分區(qū)后，肯定會因?yàn)榻邮懿坏絃eader的心跳而重新發(fā)生選舉，就會出現(xiàn)兩個(gè)Leader。這樣就分成了2部分。

• Leader B節(jié)點(diǎn)+Follower A
• Leader E+Follower C+Flollwer D

原來的節(jié)點(diǎn)總數(shù)是5，大多數(shù)等于3.那么客戶端往LeaderB上發(fā)的消息都是未提交的。只有發(fā)給E才能被提交。

等網(wǎng)絡(luò)恢復(fù)后E節(jié)點(diǎn)Termid較大成為Leader節(jié)點(diǎn)，并同步節(jié)點(diǎn)數(shù)據(jù)。Leader B降為Follower節(jié)點(diǎn)

7. Lease機(jī)制

Lease機(jī)制，翻譯過來是租約機(jī)制，是維護(hù)分布式系統(tǒng)數(shù)據(jù)一致性的一種常用工具。

Lease機(jī)制有如下幾個(gè)特點(diǎn)：

• Lease是頒發(fā)者對一段時(shí)間內(nèi)數(shù)據(jù)一致性的承諾
• 頒發(fā)者發(fā)出Lease后，不管是否被接受，只要Lease不過期，頒發(fā)者都會被按照協(xié)議遵守承諾
• Lease的持有者只能在Lease的有效期內(nèi)使用承諾，一旦Lease超時(shí)，持有者需要放棄執(zhí)行，重新申請Lease

Lease機(jī)制能解決什么問題呢？

分布式系統(tǒng)中，如何確認(rèn)一個(gè)節(jié)點(diǎn)是否正常工作。考慮如下場景

Node1是主節(jié)點(diǎn)，剩下4個(gè)副本，如果Node1發(fā)生網(wǎng)絡(luò)抖動(dòng)（Node1本身是正常的，沒有宕機(jī)），導(dǎo)致從節(jié)點(diǎn)無法接收到心跳。他們就會再選出一個(gè)主節(jié)點(diǎn)。

這種場景解決思路有4種：

• 設(shè)計(jì)能容忍雙主的協(xié)議
• Raft協(xié)議：通過TermId大的通過給低的
• Lease機(jī)制
• 去中心化-Gossip協(xié)議

Lease如何處理這種情況呢？

引入了一個(gè)中心節(jié)點(diǎn)，負(fù)責(zé)下發(fā)有時(shí)效性的Lease給主節(jié)點(diǎn)（這個(gè)有效期內(nèi)不管你出啥問題，我就認(rèn)你）

如果網(wǎng)絡(luò)出現(xiàn)問題了，重新選了主節(jié)點(diǎn)。

Lease未過期，新的主節(jié)點(diǎn)去申請會被拒絕

網(wǎng)絡(luò)恢復(fù)了，原來的主節(jié)點(diǎn)可以繼續(xù)續(xù)期

如果是原來的主節(jié)點(diǎn)是真的宕機(jī)了，那么它的有效期過后，新的主節(jié)點(diǎn)就能申請成功了。

Lease時(shí)間長短一般取1-10秒。太短網(wǎng)絡(luò)壓力太大，太長則收回承諾的時(shí)間也長，影響可用性

Lease的容錯(cuò)

主節(jié)點(diǎn)宕機(jī) Lease的機(jī)制天生可容忍網(wǎng)絡(luò)、Lease接收方的出錯(cuò)，時(shí)間即Lease剩余過期時(shí)長

中心節(jié)點(diǎn)異常 中心節(jié)點(diǎn)異常會使得所有節(jié)點(diǎn)沒有Lease，解決辦法是使用小集群作為頒發(fā)者

時(shí)差問題 中心節(jié)點(diǎn)和主節(jié)點(diǎn)之間可能存在時(shí)差問題，需要校對

應(yīng)用：

GFS(Google 文件系統(tǒng))中，Master通過lease機(jī)制決定哪個(gè)是主副本，lease在給各節(jié)點(diǎn)的心跳響應(yīng)消息中攜帶。收不到心跳時(shí)，則等待lease過期，再頒發(fā)給其他節(jié)點(diǎn)。

chubby中，paxos選主后，從節(jié)點(diǎn)會給主頒發(fā)lease，在期限內(nèi)不選其他節(jié)點(diǎn)為主。另一方面，主
節(jié)點(diǎn)給每個(gè)client節(jié)點(diǎn)發(fā)送lease，用于判斷client死活。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的分布式概念与协议的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。