[[409063]]

本文轉(zhuǎn)載自微信公眾號「木鳥雜記」，作者穆尼奧。轉(zhuǎn)載本文請聯(lián)系木鳥雜記公眾號。

分布式系統(tǒng)有很多經(jīng)典的套路，也即設(shè)計(jì)模式。每個設(shè)計(jì)模式可以解決經(jīng)典的一類問題，積累的多了，便可以稍加變化，進(jìn)行取舍，設(shè)計(jì)出貼合需求的架構(gòu)組織。但似乎大家在這方面經(jīng)驗(yàn)分享的不太多，因此之后打算總結(jié)一些工作和學(xué)習(xí)的經(jīng)驗(yàn)，既是備忘，也希望對大家有些助益。篇幅所限、能力所囿，難以面面俱到，又或疏于精確。不當(dāng)之處，歡迎指正。

每篇將以概述背景、架構(gòu)模塊、總結(jié)延伸來分別解析，本篇是第一篇：Master-Workers 架構(gòu)。

概述

Master-Workers 架構(gòu)(粗譯為主從架構(gòu))是分布式系統(tǒng)中常見的一種組織方式，如 GFS 中的 Master、ChunkServers;MapReduce 中的 Master、Workers。面對分布式系統(tǒng)中一堆分離的機(jī)器資源，主從架構(gòu)是一種最自然、直白的組織方式——就像一群人，有個說了算 leader 進(jìn)行組織、協(xié)調(diào)，才能最大化這群人的對外輸出能力。

這也是計(jì)算機(jī)系統(tǒng)中常見的一種分而治之思想的體現(xiàn)。即將一個復(fù)雜的系統(tǒng)，拆解成幾個相對高內(nèi)聚、低耦合的子模塊，定義清楚其功能邊界和交互接口，使得系統(tǒng)易于理解、維護(hù)和擴(kuò)展。對于主從架構(gòu)來說，主(Master) 通常會維護(hù)集群元信息、進(jìn)而依靠這些元信息進(jìn)行調(diào)度，從(Workers) 通常負(fù)責(zé)具體數(shù)據(jù)切片(存儲系統(tǒng))的讀寫或者作為子任務(wù)(計(jì)算系統(tǒng))的執(zhí)行單元。

架構(gòu)模塊

主從架構(gòu)系統(tǒng)，通常由單個 Master ，多個 Worker 組成。插一句，這里從英文翻譯沒有用 Slave 的原因是，我覺得 Worker 更中性一些。當(dāng)然，單個 Master 會有性能瓶頸和可用性問題，通常也有多種解決方案，后面詳說。但單個 Master 的好處是顯而易見的：Master 作為一個控制節(jié)點(diǎn)，而不用處理由多副本帶來的一致性問題，大大降低實(shí)現(xiàn)難度。

以我更熟悉一點(diǎn)的存儲系統(tǒng)架構(gòu)為例，其架構(gòu)圖通常長這樣。

master-workers architecture

除了系統(tǒng)內(nèi)部的 Master 和 Worker 外，還有使用系統(tǒng)的外部用戶。我們通常稱之為**客戶端(Client)，**Client 通過系統(tǒng)暴露的接口(如 RPC、HTTP)與系統(tǒng)進(jìn)行交互。

Master

Master 通常會存儲系統(tǒng)的元信息，什么是元信息呢?可以理解為集群組織信息在 Master 腦中的一個倒影，或者說視圖(View)：比如集群有多少 Worker、每個 Worker 有多少剩余容量、負(fù)載如何、哪些 Worker 存儲了哪些數(shù)據(jù)等等。

那元信息是怎么收集的呢?主要分兩種情況：

1. 配置?？梢岳斫鉃榧红o態(tài)信息，比如系統(tǒng)初始有多少個 Worker、Worker 的物理拓?fù)?、每個 Worker 的容量等等，Master 會在啟動時加載這些配置信息。
2. 匯報(bào)。主要是集群動態(tài)信息，Worker 在運(yùn)行時，主動將自身狀態(tài)匯報(bào)給 Master，比如 Worker 是否存活、Worker 負(fù)載信息、Worker 存了哪些數(shù)據(jù)等等。在系統(tǒng)運(yùn)行中，Worker 會定時地通過心跳(Heartbeat) 等方式，持續(xù)給 Master 匯報(bào)。

有了這些元信息，Master 就可以對整個集群情況有個掌握，從而做出一系列的決策，試舉幾例：

1. 調(diào)度(Schedule)。一個新的寫數(shù)據(jù)請求來了，要分配給哪個 Worker 負(fù)責(zé)?通常會選擇一個負(fù)載小的。
2. 均衡(Balance)。隨著 Worker 變動、數(shù)據(jù)增刪，數(shù)據(jù)在不同機(jī)器中分布可能不再均勻，在某些機(jī)器形成讀寫熱點(diǎn)、在另一些機(jī)器卻存在資源浪費(fèi)，從而影響系統(tǒng)整體性能。因此需要實(shí)時監(jiān)測，適時遷移。
3. 路由(Locate/Route)。一個讀寫請求來了，不知道去找哪個 Worker?Master 便會查詢元信息，給出對應(yīng)數(shù)據(jù)的 Worker 信息。

Master 的可用性

可以看出整個系統(tǒng)的可用性全系 Master 一身。業(yè)界也有很多解決辦法，比如：

1. 使用主備。即給 Master 做個分身，備 Master 所有元信息要時刻跟主 Master 保持一致，一旦主 Master 掛掉，分身立刻跟上。Hadoop 后來這么干過。
2. 使用共識算法(consensus algorithm)。簡單來說，就是由一堆 Master 機(jī)器來組成委員會，每個狀態(tài)變更都要通過某種算法達(dá)成共識。Google 的 Spanner 就是這么干的。
3. 無主。系統(tǒng)中不再有 Master，人人平等，然后通過某種策略，比如說一致性哈希(consistent hash)，來分活干。Amazon 的 Dynamo 是這么干的。

每種策略都是比較大的主題，以后可以分別單開一篇，本文限于篇幅不再展開。

Workers

在存儲系統(tǒng)中，Workers 會存儲實(shí)際數(shù)據(jù)，并對外提供數(shù)據(jù) IO 服務(wù)。

從單機(jī)視角來看，Worker 需要設(shè)計(jì)一個貼合業(yè)務(wù)需求的單機(jī)引擎，高效的存儲數(shù)據(jù)。單機(jī)引擎設(shè)計(jì)也是一個很大的話題，這里簡要提一嘴：

1. 索引設(shè)計(jì)：比如 B+ 樹、LSM-tree、哈希索引等等。
2. 底層系統(tǒng)：是用裸盤還是文件系統(tǒng)。
3. 存儲介質(zhì)：使用可持久化內(nèi)存、固態(tài)硬盤還是機(jī)械硬盤。

從多機(jī)視角來看，機(jī)器的數(shù)量一上去，系統(tǒng)中單臺機(jī)器出現(xiàn)故障的概率便大大提高。為了應(yīng)對這種常態(tài)化的故障，需要：

運(yùn)維的自動化。機(jī)器不可用后要自動剔除，修好后要便捷上線。

數(shù)據(jù)的冗余化。機(jī)器故障后數(shù)據(jù)不能丟，因此每份數(shù)據(jù)要多副本存放、使用 EC 算法做冗余。

小結(jié)

Master-Workers 架構(gòu)是分布式系統(tǒng)中最常用的一種組織方式。該架構(gòu)類似于人類社群的組織方式，將系統(tǒng)的職責(zé)進(jìn)行拆解，Master 收集元信息，并據(jù)此進(jìn)行任務(wù)調(diào)度;Workers 負(fù)責(zé)實(shí)際工作負(fù)載，需要設(shè)計(jì)高效的單機(jī)引擎，并配合全局做冗余。該架構(gòu)簡單直接，但威力強(qiáng)大。