《分佈式原理與算法解析》學習筆記

《分佈式原理與算法解析》學習筆記

 

00分佈式中的四縱四橫

 

四橫：分佈式計算、分佈式數據存儲與管理、分佈式通信、分佈式資源池化；四縱：分佈式協同、分佈式調度、分佈式追蹤與高可用、分佈式部署。

 

在一定的資源上，進行一定通信，通過一定計算，完成一定數據的加工和處理，從而對外提供特定的服務。

 

01分佈式緣何而起：從單兵，到游擊隊，到集團軍

 

分佈式其實就是將相同或相關的程序運行在多臺計算機上，從而實現特定目標的一種計算方式。

 

產生分佈式的最主要驅動力量，是我們對於性能、可用性及可擴展性的不懈追求。

 

02分佈式系統的指標：啥是分佈式的三圍

 

性能、資源、可用性和可擴展性。

 

QPS：查詢數每秒，TPS：事務數每秒，BPS：比特數每秒

 

系統的可用性可以用系統停止服務的時間與總的時間之比衡量。

 

可擴展性，指的是分佈式系統通過擴展集羣機器規模提高系統性能（吞吐量、響應時間、完成時間）、存儲容量、計算能力的特性，是分佈式系統的特有性質。

 

03分佈式互斥：有你沒我，有我沒你

 

在分佈式系統中，排他性的資源訪問方式，叫作分佈式互斥。這種被互斥訪問的共享資源叫作臨界資源。

 

解決這個問題的方法有：

 

霸道總裁：集中式算法，也可以叫中央服務器算法。

 

民主協商：分佈式算法。

 

輪值CEO：令牌環算法。

 

04分佈式選舉：國不可一日無君

對於一個集羣，多個節點如何協同，怎麼管理。

 

選舉一個“領導”來負責調度和管理其他節點。

 

分佈式選舉常見算法：

 

長者爲大：Bully算法

 

在所有活着的節點中，選取ID最大的節點作爲主節點。

 

民主投票：Raft算法

 

具有優先級的民主投票：ZAB算法

 

05分佈式共識：存異求同

 

分佈式共識就是在多個節點均可獨自操作或記錄的情況下，使得所有節點針對某個狀態達成一致的過程。通過共識機制，可以使得分佈式系統中的多個節點的數據達成一致。

 

常見分佈式共識方法：

 

PoW（Proof-of-Work，工作量證明）：是以每個節點或服務器的計算能力來競爭記賬權的機制，是一種使用工作量證明機制的共識算法。

 

PoS（Proof-of-Stake，權益證明）：由系統權益代替算力來決定區塊記賬權，擁有的權益越大越獲得記賬權的概率就越大。

 

DPoS（Delegated Proof of Stake，委託權益證明）：類似股份制公司的董事會制度，普通股民雖然擁有股權，但進不了董事會，他們可以投票選舉代表（受託人）代他們做決策。DPoS 是由被社區選舉的可信帳戶（受託人，比如得票數排行前 101 位）來擁有記賬權。

 

一致性強調的是結果，共識強調的是達成一致的過程，共識算法是保障系統滿足不同程度一致性的核心技術。

 

06分佈式事務：All or nothing

 

關於事務：ACID

 

A：Atomicity , 原子性，事務要麼全部執行，要麼全部不執行。

 

C: Consistency，一致性，事務執行前到執行後，數據的完整性要保持一致。

 

I: Isolation，隔離性，多個事務並行執行時，互不干擾。

D: Durability，持久性，一個事務完成了，對數據庫的操作就永久保存了。

 

分佈式事務，就是在分佈式系統中運行的事務，由多個本地事務組合而成。

 

BASE 理論，該理論的一個關鍵點就是採用最終一致性代替強一致性。

 

常見的實現分佈式事務的方法：

 

基於 XA 協議的二階段提交協議方法：協調者下發請求事務操作，參與者將操作結果通知協調者，協調者根據所有參與者的反饋結果決定各參與者是要提交操作還是撤銷操作。

 

三階段提交協議方法：三階段提交引入了超時機制和準備階段。

 

基於消息的最終一致性方法：例如MQ消息中間件。

 

BASE 理論包括基本可用（Basically Available）、柔性狀態（Soft State）和最終一致性（Eventual Consistency）。

 

基本可用：分佈式系統出現故障的時候，允許損失一部分功能的可用性。比如，某些電商 618 大促的時候，會對一些非核心鏈路的功能進行降級處理。

 

柔性狀態：在柔性事務中，允許系統存在中間狀態，且這個中間狀態不會影響系統整體可用性。比如，數據庫讀寫分離，寫庫同步到讀庫（主庫同步到從庫）會有一個延時，其實就是一種柔性狀態。

 

最終一致性：事務在操作過程中可能會由於同步延遲等問題導致不一致，但最終狀態下，數據都是一致的。

 

07分佈式鎖：關鍵重地，非請勿入

 

鎖是實現多線程同時訪問同一共享資源，保證同一時刻只有一個線程可訪問共享資源所做的一種標記。

 

與普通鎖不同的是，分佈式鎖是指分佈式環境下，系統部署在多個機器中，實現多進程分佈式互斥的一種鎖。爲了保證多個進程能看到鎖，鎖被存在公共存儲（比如 Redis、Memcache、數據庫等三方存儲中），以實現多個進程併發訪問同一個臨界資源，同一時刻只有一個進程可訪問共享資源，確保數據的一致性。

 

實現分佈式鎖的 3 種主流方法，即：

基於數據庫實現分佈式鎖，這裏的數據庫指的是關係型數據庫；

基於緩存實現分佈式鎖；

基於 ZooKeeper 實現分佈式鎖。

 

基於數據庫實現的分佈式鎖比較簡易，絕招在於創建一張鎖表，爲申請者在鎖表裏建立一條記錄，記錄建立成功則獲得鎖，消除記錄則釋放鎖。

 

所謂基於緩存，也就是說把數據存放在計算機內存中，不需要寫入磁盤，減少了 IO 讀寫。

 

Redis 通過隊列來維持進程訪問共享資源的先後順序。Redis 鎖主要基於 setnx 函數實現分佈式鎖，當進程通過 setnx 函數返回 1 時，表示已經獲得鎖。排在後面的進程只能等待前面的進程主動釋放鎖，或者等到時間超時才能獲得鎖。

 

使用 ZooKeeper 可以完美解決設計分佈式鎖時遇到的各種問題，比如單點故障、不可重入、死鎖等問題。雖然 ZooKeeper 實現的分佈式鎖，幾乎能涵蓋所有分佈式鎖的特性，且易於實現，但需要頻繁地添加和刪除節點，所以性能不如基於緩存實現的分佈式鎖。

 

08分佈式技術是如何引爆人工智能的？

 

數據、模型（也叫作算法）、算力是人工智能的三大核心。可以說，在一定程度上數據決定了機器學習的上限，而模型爲逼近這個上限提供方法，因此數據處理和模型訓練是人工智能的關鍵技術，算力決定了數據處理和模型訓練的實用性能，而分佈式技術就是解決算力的不二妙招。

 

09 分佈式體系結構之集中式結構：一人在上，萬人在下

 

主要講解了Google Borg、Kubernetes、Apache Mesos 三個經典的集羣管理系統。

 

Borg 是 Google 內部使用的集羣管理系統，採用了典型的集中式結構，負責提交、調度、開始、重啓和管理 Google 運行在其上的所有應用。

 

Kubernetes 是 Google 開源的容器集羣管理系統，是 Borg 的一個開源版本。

 

Apache 旗下的開源分佈式資源管理框架 Mesos ，它被稱爲是分佈式系統的內核，最初由加州大學伯克利分校的 AMPLab 開發，後在 Twitter 得到廣泛使用。

 

10 分佈式體系結構之非集中式結構：衆生平等

 

Akka 集羣

 

Akka 框架基於 Actor 模型，提供了一個用於構建可擴展的、彈性的、快速響應的應用程序的平臺。其中，Actor 是一個封裝了狀態和行爲的對象，它接收消息並基於該消息執行計算。Actor 之間互相隔離，不共享內存，但 Actor 之間可通過交換消息（mail）進行通信（每個 Actor 都有自己的 MailBox）。

 

Redis 集羣

 

Redis 是一個開源的高性能分佈式 key-value 數據庫，應用廣泛，其特徵主要表現爲：

支持數據的持久化，可以將內存中的數據保存在磁盤中，重啓時可以再次加載並使用；

支持多種數據結構，不僅支持簡單的 key-value 類型的數據，同時還提供 list、set、hash 等數據結構的存儲；

支持數據的備份，即 Master/Slave 模式的數據備份。

 

Cassandra 集羣

 

Cassandra 集羣的系統架構是基於一致性哈希的完全 P2P 結構，沒有 Master 的概念，所有節點都是同樣的角色，徹底避免了因爲單點問題導致的系統不穩定。Cassandra 集羣節點間的狀態同步，也是通過 Gossip 協議來進行 P2P 通信的。

 

11 分佈式調度架構之單體調度：物質文明、精神文明一手抓

 

單體調度，就是任務和分佈式系統中的空閒資源直接進行匹配調度。也就是說，調度器同時管理任務和資源，如果把資源比作“物質文明”，把任務比作“精神文明”，那麼單體調度就是“物質文明和精神文明一手抓”。

 

布式系統中的單體調度是指，一個集羣中只有一個節點運行調度進程，該節點對集羣中的其他節點具有訪問權限，可以蒐集其他節點的資源信息、節點狀態等進行統一管理，同時根據用戶下發的任務對資源的需求，在調度器中進行任務與資源匹配，然後根據匹配結果將任務指派給其他節點。

 

單體調度器擁有全局資源視圖和全局任務，可以很容易地實現對任務的約束並實施全局性的調度策略。

 

12 分佈式調度架構之兩層調度：物質文明、精神文明兩手抓

 

什麼是兩層調度？

 

把資源和任務分開調度，也就是說一層調度器只負責資源管理和分配，另外一層調度器負責任務與資源的匹配呢。

 

兩層調度結構對應的就是兩層調度器，資源的使用狀態同時由中央調度器和第二層調度器管理，中央調度器從整體上進行資源的管理與分配，將資源分配到第二層調度器；再由第二層調度器負責將資源與具體的任務配對，因此第二層調度可以有多個調度器，以支持不同的任務類型。

 

兩層調度器的職責分別是：第一層調度器負責管理資源並向框架分配資源，第二層調度器接收分佈式集羣管理系統中第一層調度器分配的資源，然後根據任務和接收到的資源進行匹配。

 

以 Mesos 爲基礎的分佈式資源管理與調度框架包括兩部分，即 Mesos 資源管理集羣和框架。

 

13 分佈式調度架構之共享狀態調度：物質文明、精神文明多手協商抓

 

一種新的調度器架構被設計了出來。這種架構基本上沿襲了單體調度器的模式，通過將單體調度器分解爲多個調度器，每個調度器都有全局的資源狀態信息，從而實現最優的任務調度，提供了更好的可擴展性。也就是說，這種調度架構在支持多種任務類型的同時，還能擁有全局的資源狀態信息。要做到這一點，這種調度架構的多個調度器需要共享集羣狀態，包括資源狀態和任務狀態等。因此，這種調度架構，我們稱之爲共享狀態調度器。

 

以Omega爲例講解了共享狀態調度。

 

15  分佈式計算模式之MR：一門同流合污的藝術

 

常見的4種計算模式，包括 MapReduce、Stream、Actor 和流水線。

 

用分治法解決問題的核心步驟是：

分解原問題。將原問題分解爲若干個規模較小，相互獨立，且與原問題形式相同的子問題。

求解子問題。若子問題規模較小且容易被解決則直接求解，否則遞歸地求解各個子問題。

合併解，就是將各個子問題的解合併爲原問題的解。

 

MapReduce 分爲 Map 和 Reduce 兩個核心階段，其中 Map 對應“分”，即把複雜的任務分解爲若干個“簡單的任務”執行；Reduce 對應着“合”，即對 Map 階段的結果進行彙總。

 

整個 MapReduce 的工作流程主要可以概括爲 5 個階段，即：Input（輸入）、Splitting（拆分）、Mapping（映射）、Reducing（化簡）以及 Final Result（輸出）。

 

Fork-Join 是 Java 等語言或庫提供的原生多線程並行處理框架，採用線程級的分而治之計算模式。它充分利用多核 CPU 的優勢，以遞歸的方式把一個任務拆分成多個“小任務”，把多個“小任務”放到多個處理器上並行執行，即 Fork 操作。當多個“小任務”執行完成之後，再將這些執行結果合併起來即可得到原始任務的結果，即 Join 操作。

 

16 分佈式計算模式之Stream：一門背鍋的藝術

 

處理流數據任務的計算模式，在分佈式領域中叫作 Stream。

 

在分佈式領域中，處理流數據的計算模式，就是流計算，也叫作 Stream。

 

使用流計算進行數據處理，一般包括 3 個步驟：

第一步，提交流式計算作業。

第二步，加載流式數據進行流計算。

第三步，持續輸出計算結果。

 

17 分佈式計算模式之Actor：一門甩鍋的藝術

 

Actor 類似於一個“黑盒”對象，封裝了自己的狀態和行爲，使得其他 Actor 無法直接觀察到它的狀態，調用它的行爲。多個 Actor 之間通過消息進行通信，這種消息類似於電子郵箱中的郵件。Actor 接收到消息之後，纔會根據消息去執行計算操作。

 

Actor 模型又是什麼呢？Actor 模型，代表一種分佈式並行計算模型。這種模型有自己的一套規則，規定了 Actor 的內部計算邏輯，以及多個 Actor 之間的通信規則。在 Actor 模型裏，每個 Actor 相當於系統中的一個組件，都是基本的計算單元。

 

Actor 模型的三要素是狀態、行爲和消息。

 

Actor 關鍵特徵：

實現了更高級的抽象。

非阻塞性。

無需使用鎖。

併發度高。

易擴展。

 

18 分佈式計算模式之流水線：你方唱罷我登場

 

計算機中的流水線（Pipeline）技術是一種將每條指令拆分爲多個步驟，多條指令的不同步驟重疊操作，從而實現幾條指令並行處理的技術。現代 CPU 指令採用了流水線設計，將一條 CPU 指令分爲取指（IF）、譯碼（ID）、執行（EX）、訪存（MEM）、回寫（WB）五級流水線來執行。

 

MapReduce 以任務爲粒度，將大的任務劃分成多個小任務，每個任務都需要執行完整的、相同的步驟，同一任務能被並行執行，可以說是任務並行的一種計算模式；

而流水線計算模式以步驟爲粒度，一個任務拆分爲多個步驟，每個步驟執行的是不同的邏輯，多個同類型任務通過步驟重疊以實現不同任務的並行計算，可說是數據並行的一種模式。

 

19 分佈式通信之遠程調用：我是你的千里眼

 

本地調用通常指的是，進程內函數之間的相互調用；而遠程調用，是進程間函數的相互調用，是進程間通信 IPC（Inter-Process Communication）的一種方式。

 

RPC 與本地調用主要有三點不同：

 

第一個區別是，調用 ID 和函數的映射。

 

第二個區別是，序列化和反序列化。

 

第三個區別是，網絡傳輸協議。

 

Dubbo 的架構主要包括 4 部分：

服務提供方。服務提供方會向服務註冊中心註冊自己提供的服務。

服務註冊中心。服務註冊與發現中心，負責存儲和管理服務提供方註冊的服務信息和服務調用方訂閱的服務類型等。

服務調用方。根據服務註冊中心返回的服務所在的地址列表，通過遠程調用訪問遠程服務。

監控中心。統計服務的調用次數和調用時間等信息的監控中心，以方便進行服務管理或服務失敗分析等

 

RMI 是一個基於 Java 環境的應用編程接口，能夠讓本地 Java 虛擬機上運行的對象，像調用本地對象一樣調用遠程 Java 虛擬機上的對象。

 

同步調用和異步調用的區別是，是否等待被調用方執行完成並返回結果。

 

20 分佈式通信之發佈訂閱：送貨上門

 

發佈訂閱的三要素是生產者、消費者和消息中心，生產者負責產生數據放到消息中心，消費者向消息中心訂閱自己感興趣的消息，當發佈者推送數據到消息中心後，消息中心根據消費者訂閱情況將相關數據推送給對應的訂閱者。

 

在分佈式通信領域中，消息系統一般有兩種典型的模式。一種是點對點模式（P2P，Point to Point），另一種是發佈訂閱模式（Pub/Sub，Publish/Subscribe）。

 

Kafka 是一種典型的發佈訂閱消息系統，其系統架構也是包括生產者、消費者和消息中心三部分。

 

生產者（Producer）負責發佈消息到消息中心，比如電子論文的會議方或出版社；

消費者（Consumer）向消息中心訂閱自己感興趣的消息，獲得數據後進行數據處理，比如訂閱電子論文的老師或學生；

消息中心（Broker）負責存儲生產者發佈的消息和管理消費者訂閱信息，根據消費者訂閱信息，將消息推送給消費者，比如論文網站。在 Kafka 中，消息中心本質上就是一組服務器，也可以說是 Kafka 集羣。

 

發佈訂閱模式的關鍵特徵：

實現了系統解耦，易於維護。

實現了異步執行，避免高負載。

 

21  分佈式通信之消息隊列：貨物自取

 

隊列是一種具有先進先出特點的數據結構，消息隊列是基於隊列實現的，存儲具有特定格式的消息數據，比如定義一個包含消息類型、標誌消息唯一性的 ID、消息內容的一個結構體作爲消息數據的特定格式。消息以特定格式放入這個隊列的尾部後可以直接返回，並不需要系統馬上處理，之後會有其他進程從隊列頭部開始讀取消息，按照消息放入的順序逐一處理。

 

消息隊列的核心結構：

生產者。生產者會產生消息或數據，並將消息或數據插入到消息隊列中。

消息隊列。一種具有先進先出特點的數據結構，用於存儲消息。

消費者。從消息隊列中獲取消息或數據，進行相關處理。

 

RocketMQ

 

NameServer Cluster，指的是名字服務器集羣。這個集羣的功能與 Kafka 中引入的 ZooKeeper 類似，提供分佈式服務的協同和管理功能，在 RocketMQ 中主要是管理 Broker 的信息，包括有哪些 Broker、Broker 的地址和狀態等，以方便生產者獲取 Broker 信息發佈消息，以及訂閱者根據 Broker 信息獲取消息。

 

Producer Cluster，指的是生產者集羣，負責接收用戶數據，然後將數據發佈到消息隊列中心 Broker Cluster。那麼，生產者按照集羣的方式進行部署，好處是什麼呢？在我看來，好處可以概括爲以下兩點：一是，多個 Producer 可以併發接收用戶的輸入數據，提升業務處理效率；二是，考慮到可靠性問題，如果只有一個 Producer 接收用戶輸入數據，當這個 Producer 故障後，整個業務就無法運行了。

 

Consumer Cluster，指的是消費者集羣，負責從 Broker 中獲取消息進行消費。Consumer 以集羣方式進行部署的好處是，提升消費者的消費能力，以避免消息隊列中心存儲溢出，消息被丟棄。

 

Broker Cluster，指的是 Broker 集羣，負責存儲 Producer Cluster 發佈的數據，以方便消費者進行消費。

 

23  CAP理論：這頂帽子我不想要

 

C 代表 Consistency，一致性，是指所有節點在同一時刻的數據是相同的，即更新操作執行結束並響應用戶完成後，所有節點存儲的數據會保持相同。

 

A 代表 Availability，可用性，是指系統提供的服務一直處於可用狀態，對於用戶的請求可即時響應。

 

P 代表 Partition Tolerance，分區容錯性，是指在分佈式系統遇到網絡分區的情況下，仍然可以響應用戶的請求。網絡分區是指因爲網絡故障導致網絡不連通，不同節點分佈在不同的子網絡中，各個子網絡內網絡正常。

 

24  分佈式數據存儲系統之三要素：顧客、導購與貨架

 

分佈式存儲系統的核心邏輯，就是將用戶需要存儲的數據根據某種規則存儲到不同的機器上，當用戶想要獲取指定數據時，再按照規則到存儲數據的機器裏獲取。

 

這個過程就是分佈式存儲系統中獲取數據的通用流程，顧客、導購和貨架組成了分佈式存儲系統的三要素，分別對應着分佈式領域中的數據生產者 / 消費者、數據索引和數據存儲。

 

數據分片技術，是指分佈式存儲系統按照一定的規則將數據存儲到相對應的存儲節點中，或者到相對應的存儲節點中獲取想要的數據，這是一種很常用的導購技術。這種技術，一方面可以降低單個存儲節點的存儲和訪問壓力；另一方面，可以通過規定好的規則快速找到數據所在的存儲節點，從而大大降低搜索延遲，提高用戶體驗。

 

25  數據分佈方式之哈希與一致性哈希：“掐指一算”與“掐指兩算”的事

 

一致性哈希同樣是採用哈希函數，進行兩步哈希：

1.對存儲節點進行哈希計算，也就是對存儲節點做哈希映射；

2.當對數據進行存儲或訪問時，首先對數據進行映射得到一個結果，然後找到比該結果大的第一個存儲節點，就是該數據應該存儲的地方。我會在下面的內容中，與你詳細介紹其中的原理。

 

一致性哈希是指將存儲節點和數據都映射到一個首尾相連的哈希環上，存儲節點可以根據 IP 地址進行哈希，數據通常通過順時針方向尋找的方式，來確定自己所屬的存儲節點，即從數據映射在環上的位置開始，順時針方向找到的第一個存儲節點。

 

帶有限負載的一致性哈希方法比較適合同類型節點、節點規模會發生變化的場景。

 

哈希、一致性哈希、帶有限負載的一致性哈希，都沒有考慮節點異構性的問題。

 

26 分佈式數據複製技術：分身有術

 

數據複製是一種實現數據備份的技術。

 

數據複製技術方法，大體上有三類：

第一類方法，比較注重一致性，比如同步複製技術；

第二類方法，則更注重可用性，比如異步複製技術；

第三類方法，是介於前兩者之間的，比如半同步複製技術。

 

同步複製技術是指，當用戶請求更新數據時，主數據庫必須要同步到備數據庫之後纔可給用戶返回，即如果主數據庫沒有同步到備數據庫，用戶的更新操作會一直阻塞。這種方式保證了數據的強一致性，但犧牲了系統的可用性。

 

異步複製技術是指，當用戶請求更新數據時，主數據庫處理完請求後可直接給用戶響應，而不必等待備數據庫完成同步，即備數據庫會異步進行數據的同步，用戶的更新操作不會因爲備數據庫未完成數據同步而導致阻塞。顯然，這種方式保證了系統的可用性，但犧牲了數據的一致性。

 

同步複製技術會滿足數據的強一致性，但會犧牲一定的可用性；異步複製技術會滿足高可用，但一定程度上犧牲了數據的一致性。介於兩者中間的是，半同步複製技術。半同步複製技術的核心是，用戶發出寫請求後，主數據庫會執行寫操作，並給備數據庫發送同步請求，但主數據庫不用等待所有備數據庫回覆數據同步成功便可響應用戶，也就是說主數據庫可以等待一部分備數據庫同步完成後響應用戶寫操作執行成功。

 

27 分佈式數據之緩存技術：“身手鑰錢”隨身帶

 

緩存技術一般是指，用一個更快的存儲設備存儲一些經常用到的數據，供用戶快速訪問。用戶不需要每次都與慢設備去做交互，因此可以提高訪問效率。

 

Redis 中與緩存關係最緊密的三個特性：支持多數據結構、支持持久化和主備同步。

 

第一，Redis 支持多數據結構。

第二，Redis 支持持久化。

第三，Redis 支持主備同步。

 

28 分佈式高可靠之負載均衡：不患寡，而患不均

 

負載均衡可以分爲兩種：

一種是請求負載均衡，即將用戶的請求均衡地分發到不同的服務器進行處理；

另一種是數據負載均衡，即將用戶更新的數據分發到不同的存儲服務器。

 

輪詢策略

輪詢策略是一種實現簡單，卻很常用的負載均衡策略，核心思想是服務器輪流處理用戶請求，以儘可能使每個服務器處理的請求數相同。生活中也有很多類似的場景，比如，學校宿舍裏，學生每週輪流打掃衛生，就是一個典型的輪詢策略。

 

在負載均衡領域中，輪詢策略主要包括順序輪詢和加權輪詢兩種方式。

 

隨機策略

隨機策略也比較容易理解，指的就是當用戶請求到來時，會隨機發到某個服務節點進行處理，可以採用隨機函數實現。這裏，隨機函數的作用就是，讓請求儘可能分散到不同節點，防止所有請求放到同一節點或少量幾個節點上。

 

29 分佈式高可靠之流量控制：大禹治水，在疏不在堵

 

漏桶策略

漏桶策略適用於間隔性突發流量且流量不用即時處理的場景，即可以在流量較小時的“空閒期”，處理大流量時流入漏桶的流量；不適合流量需要即時處理的場景，即突發流量時可以放入桶中，但缺乏效率，始終以固定速率進行處理。

 

令牌桶策略

令牌桶策略，也是一個很形象的名字，指的是桶裏放着很多令牌，請求只有拿到令牌才能被服務器處理。

 

30 分佈式高可用之故障隔離：當斷不斷，反受其亂

 

分佈式故障隔離策略

 

一類是以系統功能模塊爲粒度進行隔離。比如，通過系統功能 / 服務劃分，將系統分爲多個功能 / 服務模塊，各個功能 / 服務模塊之間實現松耦合，即一個功能 / 服務模塊出現故障，不會影響其他功能 / 服務模塊，根據功能模塊或服務由線程執行還是進程執行，通常分爲線程級隔離、進程級隔離。

 

另一類是，通過資源隔離來實現。比如，系統中各個模塊擁有自己獨立的資源，不會發生資源爭搶，從而大大提升系統性能。根據資源所屬粒度，通常包括進程級隔離（比如採用容器隔離）、虛擬機隔離、服務器隔離和機房隔離等。

 

線程級的故障隔離策略，在生產環境中較爲常用，尤其對於單體應用（單進程多線程的應用）。

 

進程級隔離

一種常用的方式就是，將系統按照功能分爲不同的進程，分佈到相同或不同的機器中。如果系統的進程分佈到不同機器上的話，從資源的角度來看，也可以說成是主機級的故障隔離。因爲從另一個層面看，系統確實分佈到了不同機器上，當某個機器出現故障時，不會對其他機器造成影響。

 

資源隔離

簡單來說，資源隔離就是將分佈式系統的所有資源分成幾個部分，每部分資源負責一個模塊，這樣系統各個模塊就不會爭搶資源，即資源之間互不干擾。這種方式不僅可以提高硬件資源利用率，也便於系統的維護與管理，可以大幅提升系統性能。

 

31 分佈式高可用之故障恢復：知錯能改，善莫大焉

 

基於歷史心跳消息預測故障的策略，也就是我們常說的 φ 值故障檢測。

總結：以上學習筆記摘自極客時間聶鵬程老師的《分佈式技術原理與算法解析》。通過此專欄的學習，對分佈式有了一個大體的瞭解。之前經常聽到一些高大上的詞彙：dubbo、kafka、zokeeper等，對於它們背後的原理及產生這種技術的歷史發展進程都不太清楚。這個專欄可以說是爲我們打下了理論基礎，其中一些篇章值得反覆閱讀與理解。

 

以下爲課程的大綱腦圖：