分布式架構基礎、Paxos算法、Raft算法、系統網絡通信

SpringCloudAlibaba微服務實戰教程系列

-------------------------目錄-------------------------------------

第一部分：分布式架構理論

　　一、分布式與集群區別

　　二、傳統架構的弊端：

　　三、分布式系統面臨的問題

　　四、分布式中的一致性理論(CAP與BASE理論)

　　五、一致性協議：2PC協議

　　六、一致性協議：3PC協議

　　七、分布式一致性：Paxos算法

　　八、分布式一致性：Raft算法

第二部分：分布式系統設計策略 

　　心跳機制、高可用、容錯性、負載均衡

 -----------------------------------------------------------------

第一部分：分布式架構理論

 一、分布式與集群區別

　　分布式：是多個人在一起做不同的事情；

　　集群：是多個在一起做同樣的事情；

二、傳統架構的弊端：

互聯網發展單機處理所有的業務弊端比較明顯，比如修改下單業務的邏輯，用戶登錄的功能沒有修改也需要重啟項目，同時團隊開發同一個項目溝通協作的成本也會隨着業務的發展而增多。

1、升級單機處理能力的性價比越來越低。

2、單機處理能力存在瓶頸。

3、穩定性和可用性這兩個標准很難達到。

三、分布式系統面臨的問題

1、通信異常

主要包括消息丟失與消息延時：網絡本來不可靠每次通信都可能存在網絡不可用的風險，最終導致分布式系統無法順利的進行網絡通信，另一種是分布式節點正常執行也會出現單機延時處理，從而影響整個業務處理的消息丟失和消息延遲

 2、網絡分區

網絡之間出現網絡不通，但是各個子節點網絡正常通信，導致真個系統網絡環境被分隔獨立的區域，在分布式中就會存在局部小集群，對與數理的事務處理分布式一致性挑戰比較大

3、節點故障

節點故障是分布式系統比較常見的問題，制的是組成分布式系統的服務器節點出現宕機或者僵死

4、三態

分布式系統每次請求響應存在三態：成功、失敗、超時

超時有兩種情況：

1、網絡原因請求發出后對方沒有收到，

2、請求接收方收到請求，業務處理成功，返回失敗

四、分布式中的一致性理論

首先分布式中處理數據的一致性，保證一致性使用的是多副本存儲，副本存儲就是多份拷貝；

一致性分類：強一致性、弱一致性、單調弱一致性、最終一致性。

 1、分布式理論：CAP理論

CAP理論含義：一個分布式系統中不可能同時滿足一致性（C：Consistency）、可用性（A：Availability）、分區容錯性（P：Partition tolerance）三個基本需求，最多只能同時滿足其中兩個。

一致性（C）：分布式系統中的一致性是所有節點的數據一致，或者說所有的副本數據一致，強一致性

可用性（A）：系統一直可用

分區容錯性（P）：系統在遇到節點或者網絡分區故障的時候，還可以通過一致性和可用性的服務。

CAP理論具體應用：

Redis ：屬於 cp 模型。Redis-cluster 屬於 ap 模型Redis-cluster  

Zookeeper：屬於cp模型。

MongoDB ：屬於cp模型。

Eureka：屬於ap模型。

 2、分布式理論：BASE理論

BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫。

　　BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分布式實踐的結論，是基於CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventual consistency）。接下來我們着重對BASE中的三要素進行詳細講解。

　　 基本可用：指分布式系統在出現不可預知故障的時候，允許損失部分可用性。

注意，這絕不等價於系統不可用，以下兩個就是“基本可用”的典型例子：

　　響應時間上的損失：正常情況下，一個在線搜索引擎需要0.5秒內返回給用戶相應的查詢結果，但由於出現異常（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了1~2秒。

　　功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節日大促購物高峰的時候，由於消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。

　　 弱狀態：也稱為軟狀態，和硬狀態相對，是指允許系統中的數據存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。

　　 最終一致性：強調的是系統中所有的數據副本，在經過一段時間的同步后，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。

五、一致性協議：2PC協議

什么事2PC：2PC就是分布式一致性協議，Two-Phase commit的縮寫，就是兩階段提交協議，將整個事務流程分為連個階段：准備階段和提交階段，2是兩個階段，p准備階段，c是提交階段。

例如：事務的提交（如下圖），

第一階段事務管理者向兩個資源發起准備請求，兩個資源返回准備完成，

第二階段：資源記錄日志undo/redo,事務管理者向兩個資源發起提交請求，兩個資源發起ack確認。

 

 

如果事務異常，那么第二階段事務管理這會發起事務回滾請求，都是資源返回ack確認。

優點： 原理簡單，實現方便

確定：- 同步阻塞

　　　- 單點問題

　　　- 數據不一致（第一個資源提交，第二個資源超時）

六、一致性協議：3PC協議

3PC是2PC的改進版，把二階段提交協議的“提交事務請求”過程一分為二。形成了CanCommit、PreCommit、DoCommit三個階段。

第一階段CanCommit：1、事務詢問參與者，2、各參與者返回是否支持事務

第二階段PreCommit：1、向各個參與者發送預提交處理，2、參與者記錄日志undo/redo，各參與者返回ack響應：同時等待提交commit或終止abort請求。

如果其中一個參與者下返回no或者超時，接下來協調者會發送alber終止請求

第三階段Docommit：1、向各個參與者發起提交請求，2、參與者提交事務完成后返回ack確認，

如果參與者中間事務中斷或者超時，協調者發起abort請求，執行第二階段的undo日志。

3PC詳細文章：https://blog.csdn.net/yulong1026/article/details/81002618

七、分布式一致性：Paxos算法

1、Paxos 算中中必須認識的三個角色

• Proposer：議案發起者（提議者）。提案者提倡客戶請求，試圖說服Acceptor對此達成一致，並在發生突時充當協調者以推動協議向前發展
• Acceptor：決策者，可以批准議案。Acceptor可以接受（accept）提案；如果某個提案被選（chosen），那么該提案里的value就被選定了
• Learner：最終決策的學習者（接受者）。

2、Proposer生成提案

首先Proposer在生成提案之前，需要先學習已經被選定或者可能被選定的value，然后以該value作為自己提出的議案的value，沒有value被選中的時候才可以自己決定value值，學習value是通過一個prepare請求實現的。

第一步：proposer選擇新提案編號N，然后向半數以上的Acceptor發送請求，要求每個acceptor做出下面的響應

a、Acceptor向Propose承諾保證不再接受任何編號小於N的提案。

b、如果Acceptor已經接受過提案，那么就想proposer反饋已經接受過編號小於N的，但是值是最大編號的提案值。

我們將這請求稱為編號為N的prepare請求

第二步：

a、如果Proposer收到了半數以上的Acceptor的響應，那么它就可以生成編號為N，Value為V的提案[N,V]。這里的V是所有的響應中編號最大的提案的Value。如果所有的響應中都沒有提案，那 么此時V就可以由Proposer自己選擇。

b、生成提案后，Proposer將該提案發送給半數以上的Acceptor集合，並期望這些Acceptor能接受該提案。我們稱該請求為Accept請求。

3、Acceptor接受提案

根據剛剛的介紹，一個Acceptor可能會受到來自Proposer的兩種請求，分別是Prepare請求和Accept請求，對這兩類請求作出響應的條件分別如下

Prepare請求：Acceptor可以在任何時候響應一個Prepare請求

Accept請求：在不違背Accept現有承諾的前提下，可以任意響應Accept請求

因此，對Acceptor接受提案給出如下約束：

P1a：一個Acceptor只要尚未響應過任何編號大於N的Prepare請求，那么他就可以接受這個編號為N的提

案。

 

Paxos算法推導過程：https://my.oschina.net/u/150175/blog/2992187 

Paxos算法在線演示：http://thesecretlivesofdata.com/raft/ 

 

八、分布式一致性：Raft算法

 

Raft將系統中的角色分為領導者（Leader）、跟從者（Follower）和候選者（Candidate）：

• Leader：接受客戶端請求，並向Follower同步請求日志，當日志同步到大多數節點上后告訴Follower提交日志。

• Follower：接受並持久化Leader同步的日志，在Leader告之日志可以提交之后，提交日志。

• Candidate：Leader選舉過程中的臨時角色。

https://blog.csdn.net/daaikuaichuan/article/details/98627822 

第二部分：分布式系統設計策略 

一、心跳檢測

 

二、高可用性

系統高可用性的常用設計模式包括三種：主備（Master-SLave）、互備（Active-Active）和集群（Cluster）模

式。

1.主備模式 主備模式就是Active-Standby模式，當主機宕機時，備機接管主機的一切工作，待主機恢復正常后，按

使用者的設定以自動（熱備）或手動（冷備）方式將服務切換到主機上運行。在數據庫部分，習慣稱之為MS模

式。MS模式即Master/Slave模式，這在數據庫高可用性方案中比較常用，如MySQL、Redis等就采用MS模式實現

主從復制。保證高可用，如圖所示。

 

 

MySQL之間數據復制的基礎是二進制日志文件（binary log fifile）。一台MySQL數據庫一旦啟用二進制日志后，作

為master，它的數據庫中所有操作都會以“事件”的方式記錄在二進制日志中，其他數據庫作為slave通過一個I/O線

程與主服務器保持通信，並監控master的二進制日志文件的變化，如果發現master二進制日志文件發生變化，則

會把變化復制到自己的中繼日志中，然后slave的一個SQL線程會把相關的“事件”執行到自己的數據庫中，以此實現

從數據庫和主數據庫的一致性，也就實現了主從復制。

 

2.互備模式 互備模式指兩台主機同時運行各自的服務工作且相互監測情況。在數據庫高可用部分，常見的互備是

MM模式。MM模式即Multi-Master模式，指一個系統存在多個master，每個master都具有read-write能力，會根

據時間戳或業務邏輯合並版本。

我們使用過的、構建過的MySQL服務絕大多數都是Single-Master，整個拓撲中只有一個Master承擔寫請求。比

如，基於Master-Slave架構的主從復制，但是也存在由於種種原因，我們可能需要MySQL服務具有Multi-Master的

特性，希望整個拓撲中可以有不止一個Master承擔寫請求

 

 

3.集群模式

集群模式是指有多個節點在運行，同時可以通過主控節點分擔服務請求。如Zookeeper。集群模式需要解決主控節

點本身的高可用問題，一般采用主備模式。

三、容錯性

容錯顧名思義就是IT系統對於錯誤包容的能力

容錯的處理是保障分布式環境下相應系統的高可用或者健壯性，一個典型的案例就是對於緩存穿透 問題的解決方

案。

1、緩存穿透

       描述：  緩存穿透是指緩存和數據庫中都沒有的數據，而用戶不斷發起請求，如發起為id為“-1”的數據或id為特別大不存在的數據。這時的用戶很可能是攻擊者，攻擊會導致數據庫壓力過大。

      解決方案：接口層增加校驗，如用戶鑒權校驗，id做基礎校驗，id<=0的直接攔截；從緩存取不到的數據，在數據庫中也沒有取到，這時也可以將key-value對寫為key-null，緩存有效時間可以設置短點，如30秒（設置太長會導致正常情況也沒法使用）。這樣可以防止攻擊用戶反復用同一個id暴力攻擊

2、緩存擊穿

      描述：   緩存擊穿是指緩存中沒有但數據庫中有的數據（一般是緩存時間到期），這時由於並發用戶特別多，同時讀緩存沒讀到數據，又同時去數據庫去取數據，引起數據庫壓力瞬間增大，造成過大壓力

      解決方案：設置熱點數據永遠不過期。加互斥鎖：

四、緩存雪崩

      描述：  緩存雪崩是指緩存中數據大批量到過期時間，而查詢數據量巨大，引起數據庫壓力過大甚至down機。和緩存擊穿不同的是，        緩存擊穿指並發查同一條數據，緩存雪崩是不同數據都過期了，很多數據都查不到從而查數據庫。

     解決方案：緩存數據的過期時間設置隨機，防止同一時間大量數據過期現象發生。如果緩存數據庫是分布式部署，將熱點數據均勻分布在不同搞得緩存數據庫中。設置熱點數據永遠不過期。

四、負載均衡 

 負載有硬件負載與軟件負載，負載算法：輪詢、權重、ip_hash、最少鏈接等