分布式系統(tǒng)架構(gòu)之一Master-Workers 架構(gòu)
本文轉(zhuǎn)載自微信公眾號「木鳥雜記」，作者穆尼奧。轉(zhuǎn)載本文請聯(lián)系木鳥雜記公眾號。
分布式系統(tǒng)有很多經(jīng)典的套路，也即設(shè)計模式。每個設(shè)計模式可以解決經(jīng)典的一類問題，積累的多了，便可以稍加變化，進行取舍，設(shè)計出貼合需求的架構(gòu)組織。但似乎大家在這方面經(jīng)驗分享的不太多，因此之后打算總結(jié)一些工作和學習的經(jīng)驗，既是備忘，也希望對大家有些助益。篇幅所限、能力所囿，難以面面俱到，又或疏于精確。不當之處，歡迎指正。
每篇將以概述背景、架構(gòu)模塊、總結(jié)延伸來分別解析，本篇是第一篇：Master-Workers 架構(gòu)。
概述
Master-Workers 架構(gòu)(粗譯為主從架構(gòu))是分布式系統(tǒng)中常見的一種組織方式，如 GFS 中的 Master、ChunkServers;MapReduce 中的 Master、Workers。面對分布式系統(tǒng)中一堆分離的機器資源，主從架構(gòu)是一種最自然、直白的組織方式——就像一群人，有個說了算 leader 進行組織、協(xié)調(diào)，才能最大化這群人的對外輸出能力。
這也是計算機系統(tǒng)中常見的一種分而治之思想的體現(xiàn)。即將一個復雜的系統(tǒng)，拆解成幾個相對高內(nèi)聚、低耦合的子模塊，定義清楚其功能邊界和交互接口，使得系統(tǒng)易于理解、維護和擴展。對于主從架構(gòu)來說，主(Master) 通常會維護集群元信息、進而依靠這些元信息進行調(diào)度，從(Workers) 通常負責具體數(shù)據(jù)切片(存儲系統(tǒng))的讀寫或者作為子任務(計算系統(tǒng))的執(zhí)行單元。
架構(gòu)模塊
主從架構(gòu)系統(tǒng)，通常由單個 Master ，多個 Worker 組成。插一句，這里從英文翻譯沒有用 Slave 的原因是，我覺得 Worker 更中性一些。當然，單個 Master 會有性能瓶頸和可用性問題，通常也有多種解決方案，后面詳說。但單個 Master 的好處是顯而易見的：Master 作為一個控制節(jié)點，而不用處理由多副本帶來的一致性問題，大大降低實現(xià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)進行交互。
Master
Master 通常會存儲系統(tǒng)的元信息，什么是元信息呢?可以理解為集群組織信息在 Master 腦中的一個倒影，或者說視圖(View)：比如集群有多少 Worker、每個 Worker 有多少剩余容量、負載如何、哪些 Worker 存儲了哪些數(shù)據(jù)等等。
那元信息是怎么收集的呢?主要分兩種情況：
- 配置。可以理解為集群靜態(tài)信息，比如系統(tǒng)初始有多少個 Worker、Worker 的物理拓撲、每個 Worker 的容量等等，Master 會在啟動時加載這些配置信息。
- 匯報。主要是集群動態(tài)信息，Worker 在運行時，主動將自身狀態(tài)匯報給 Master，比如 Worker 是否存活、Worker 負載信息、Worker 存了哪些數(shù)據(jù)等等。在系統(tǒng)運行中，Worker 會定時地通過心跳(Heartbeat) 等方式，持續(xù)給 Master 匯報。
有了這些元信息，Master 就可以對整個集群情況有個掌握，從而做出一系列的決策，試舉幾例：
- 調(diào)度(Schedule)。一個新的寫數(shù)據(jù)請求來了，要分配給哪個 Worker 負責?通常會選擇一個負載小的。
- 均衡(Balance)。隨著 Worker 變動、數(shù)據(jù)增刪，數(shù)據(jù)在不同機器中分布可能不再均勻，在某些機器形成讀寫熱點、在另一些機器卻存在資源浪費，從而影響系統(tǒng)整體性能。因此需要實時監(jiān)測，適時遷移。
- 路由(Locate/Route)。一個讀寫請求來了，不知道去找哪個 Worker?Master 便會查詢元信息，給出對應數(shù)據(jù)的 Worker 信息。
Master 的可用性
可以看出整個系統(tǒng)的可用性全系 Master 一身。業(yè)界也有很多解決辦法，比如：
- 使用主備。即給 Master 做個分身，備 Master 所有元信息要時刻跟主 Master 保持一致，一旦主 Master 掛掉，分身立刻跟上。Hadoop 后來這么干過。
- 使用共識算法(consensus algorithm)。簡單來說，就是由一堆 Master 機器來組成委員會，每個狀態(tài)變更都要通過某種算法達成共識。Google 的 Spanner 就是這么干的。
- 無主。系統(tǒng)中不再有 Master，人人平等，然后通過某種策略，比如說一致性哈希(consistent hash)，來分活干。Amazon 的 Dynamo 是這么干的。
每種策略都是比較大的主題，以后可以分別單開一篇，本文限于篇幅不再展開。
Workers
在存儲系統(tǒng)中，Workers 會存儲實際數(shù)據(jù)，并對外提供數(shù)據(jù) IO 服務。
從單機視角來看，Worker 需要設(shè)計一個貼合業(yè)務需求的單機引擎，高效的存儲數(shù)據(jù)。單機引擎設(shè)計也是一個很大的話題，這里簡要提一嘴：
- 索引設(shè)計：比如 B+ 樹、LSM-tree、哈希索引等等。
- 底層系統(tǒng)：是用裸盤還是文件系統(tǒng)。
- 存儲介質(zhì)：使用可持久化內(nèi)存、固態(tài)硬盤還是機械硬盤。
從多機視角來看，機器的數(shù)量一上去，系統(tǒng)中單臺機器出現(xiàn)故障的概率便大大提高。為了應對這種常態(tài)化的故障，需要：
運維的自動化。機器不可用后要自動剔除，修好后要便捷上線。
數(shù)據(jù)的冗余化。機器故障后數(shù)據(jù)不能丟，因此每份數(shù)據(jù)要多副本存放、使用 EC 算法做冗余。
小結(jié)
Master-Workers 架構(gòu)是分布式系統(tǒng)中最常用的一種組織方式。該架構(gòu)類似于人類社群的組織方式，將系統(tǒng)的職責進行拆解，Master 收集元信息，并據(jù)此進行任務調(diào)度;Workers 負責實際工作負載，需要設(shè)計高效的單機引擎，并配合全局做冗余。該架構(gòu)簡單直接，但威力強大。
