分布式系統類型多，涉及面非常廣，不同類型的系統有不同的特點，批量計算和實時計算就差別非常大。

[[276390]] 

圖片來自 Pexels

這篇文章會重點討論分布式數據系統的設計，比如分布式存儲系統，分布式搜索系統，分布式分析系統等。我們先來簡單看下 Elasticsearch 的架構。

Elasticsearch 集群架構

Elasticsearch 是一個非常著名的開源搜索和分析系統，目前被廣泛應用于互聯網多種領域中。

尤其是以下三個領域特別突出：

• 搜索領域，相對于 Solr，真正的后起之秀，成為很多搜索系統的不二之選。
• Json 文檔數據庫，相對于 MongoDB，讀寫性能更佳，而且支持更豐富的地理位置查詢以及數字、文本的混合查詢等。
• 時序數據分析處理，目前在日志處理、監控數據的存儲、分析和可視化方面做得非常好，可以說是該領域的引領者了。

Elasticsearch 的詳細介紹可以到官網查看。我們先來看一下 Elasticsearch 中幾個關鍵概念：

• 節點(Node)：物理概念，一個運行的 Elasticsearch 實例，一般是一臺機器上的一個進程。
• 索引(Index)：邏輯概念，包括配置信息 Mapping 和倒排正排數據文件，一個索引的數據文件可能會分布于一臺機器，也有可能分布于多臺機器。索引的另外一層意思是倒排索引文件。
• 分片(Shard)：為了支持更大量的數據，索引一般會按某個維度分成多個部分，每個部分就是一個分片，分片被節點(Node)管理。

一個節點(Node)一般會管理多個分片，這些分片可能是屬于同一份索引，也有可能屬于不同索引，但是為了可靠性和可用性，同一個索引的分片盡量會分布在不同節點(Node)上。分片有兩種，主分片和副本分片。

• 副本(Replica)：同一個分片(Shard)的備份數據，一個分片可能會有 0 個或多個副本，這些副本中的數據保證強一致或最終一致。

 

如上圖，用圖形表示出來可能是這樣子的：

• Index 1：藍色部分，有 3 個 Shard，分別是 P1，P2，P3，位于 3 個不同的 Node 中，這里沒有 Replica。
• Index 2：綠色部分，有 2 個 Shard，分別是 P1，P2，位于 2 個不同的 Node 中。并且每個 Shard 有一個 Replica，分別是 R1 和 R2。

基于系統可用性的考慮，同一個 Shard 的 Primary 和 Replica 不能位于同一個 Node 中。

這里 Shard1 的 P1 和 R1 分別位于 Node3 和 Node2 中，如果某一刻 Node2 發生宕機，服務基本不會受影響，因為還有一個 P1 和 R2 都還是可用的。

因為是主備架構，當主分片發生故障時，需要切換，這時候需要選舉一個副本作為新主，這里除了會耗費一點點時間外，也會有丟失數據的風險。

Index 流程

建索引(Index)的時候，一個 Doc 先是經過路由規則定位到主 Shard，發送這個 Doc 到主 Shard 上建索引，成功后再發送這個 Doc 到這個 Shard 的副本上建索引，等副本上建索引成功后才返回成功。

在這種架構中，索引數據全部位于 Shard 中，主 Shard 和副本 Shard 各存儲一份。

當某個副本 Shard 或者主 Shard 丟失(比如機器宕機，網絡中斷等)時，需要將丟失的 Shard 在其他 Node 中恢復回來。

這時候就需要從其他副本(Replica)全量拷貝這個 Shard 的所有數據到新 Node 上構造新 Shard。

這個拷貝過程需要一段時間，這段時間內只能由剩余主副本來承載流量，在恢復完成之前，整個系統會處于一個比較危險的狀態，直到 Failover 結束。

這里就體現了副本(Replica)存在的一個理由，避免數據丟失，提高數據可靠性。

副本(Replica)存在的另一個理由是讀請求量很大的時候，一個 Node 無法承載所有流量，這個時候就需要一個副本來分流查詢壓力，目的就是擴展查詢能力。

角色部署方式

接下來再看看角色分工的兩種不同方式：

 

Elasticsearch 支持上述兩種方式：

• 混合部署
• 分層部署

混合部署(如左圖)：

• 默認方式。
• 不考慮 MasterNode 的情況下，還有兩種 Node，Data Node 和 Transport Node。

這種部署模式下，這兩種不同類型 Node 角色都位于同一個 Node 中，相當于一個 Node 具備兩種功能：Data 和 Transport。

• 當有 Index 或者 Query 請求的時候，請求隨機(自定義)發送給任何一個 Node。

這臺 Node 中會持有一個全局的路由表，通過路由表選擇合適的 Node，將請求發送給這些 Node，然后等所有請求都返回后，合并結果，然后返回給用戶。一個 Node 分飾兩種角色。

• 好處就是使用極其簡單，易上手，對推廣系統有很大價值。最簡單的場景下只需要啟動一個 Node，就能完成所有的功能。
• 缺點就是多種類型的請求會相互影響，在大集群如果某一個 Data Node 出現熱點，那么就會影響途經這個 Data Node 的所有其他跨 Node 請求。如果發生故障，故障影響面會變大很多。
• Elasticsearch 中每個 Node 都需要和其余的每一個 Node 都保持 13 個連接。

這種情況下，每個 Node 都需要和其他所有 Node 保持連接，而一個系統的連接數是有上限的，這樣連接數就會限制集群規模。

• 還有就是不能支持集群的熱更新。

分層部署(如右圖)：

• 通過配置可以隔離開 Node。
• 設置部分 Node 為 Transport Node，專門用來做請求轉發和結果合并。
• 其他 Node 可以設置為 Data Node，專門用來處理數據。
• 缺點是上手復雜，需要提前設置好 Transport 的數量，且數量和 Data Node、流量等相關，否則要么資源閑置，要么機器被打爆。
• 好處就是角色相互獨立，不會相互影響，一般 Transport Node 的流量是平均分配的，很少出現單臺機器的 CPU 或流量被打滿的情況。

而 Data Node 由于處理數據，很容易出現單機資源被占滿，比如 CPU，網絡，磁盤等。

• 獨立開后，DataNode 如果出了故障只是影響單節點的數據處理，不會影響其他節點的請求，影響限制在最小的范圍內。
• 角色獨立后，只需要 Transport Node 連接所有的 Data Node，而 Data Node 則不需要和其他 Data Node 有連接。

一個集群中 Data Node 的數量遠大于 Transport Node，這樣集群的規?？梢愿?。

另外，還可以通過分組，使 Transport Node 只連接固定分組的 Data Node，這樣 Elasticsearch 的連接數問題就徹底解決了。

• 可以支持熱更新：先一臺一臺的升級 Data Node，升級完成后再升級 Transport Node，整個過程中，可以做到讓用戶無感知。

上面介紹了 Elasticsearch 的部署層架構，不同的部署方式適合不同場景，需要根據自己的需求選擇適合的方式。

Elasticsearch 數據層架構

接下來我們看看當前 Elasticsearch 的數據層架構。

數據存儲

Elasticsearch 的 Index 和 Meta，目前支持存儲在本地文件系統中，同時支持 niofs，mmap，simplefs，smb 等不同加載方式，性能最好的是直接將索引 LOCK 進內存的 mmap 方式。

默認，Elasticsearch 會自動選擇加載方式，另外可以自己在配置文件中配置。這里有幾個細節，具體可以看官方文檔。

索引和 Meta 數據都存在本地，會帶來一個問題：當某一臺機器宕機或者磁盤損壞的時候，數據就丟失了。為了解決這個問題，可以使用 Replica(副本)功能。

副本(Replica)

可以為每一個 Index 設置一個配置項：副本(Replicda)數，如果設置副本數為 2，那么就會有 3 個 Shard，其中一個是 Primary Shard，其余兩個是 Replica Shard。

這三個 Shard 會被 Mater 盡量調度到不同機器，甚至機架上，這三個 Shard 中的數據一樣，提供同樣的服務能力。

副本(Replica)的目的有三個：

• 保證服務可用性：當設置了多個 Replica 的時候，如果某一個 Replica 不可用的時候，那么請求流量可以繼續發往其他 Replica，服務可以很快恢復開始服務。
• 保證數據可靠性：如果只有一個 Primary，沒有 Replica，那么當 Primary 的機器磁盤損壞的時候，那么這個 Node 中所有 Shard 的數據會丟失，只能 Reindex 了。
• 提供更大的查詢能力：當 Shard 提供的查詢能力無法滿足業務需求的時候， 可以繼續加 N 個 Replica，這樣查詢能力就能提高 N 倍，輕松增加系統的并發度。

問題

上面說了一些優勢，這種架構同樣在一些場景下會有些問題。Elasticsearch 采用的是基于本地文件系統，使用 Replica 保證數據可靠性的技術架構，這種架構一定程度上可以滿足大部分需求和場景。

但是也存在一些遺憾：

• Replica 帶來成本浪費。為了保證數據可靠性，必須使用 Replica，但是當一個 Shard 就能滿足處理能力的時候，另一個 Shard 的計算能力就會浪費。
• Replica 帶來寫性能和吞吐的下降。每次 Index 或者 Update 的時候，需要先更新 Primary Shard，更新成功后再并行去更新 Replica，再加上長尾，寫入性能會有不少的下降。
• 當出現熱點或者需要緊急擴容的時候動態增加 Replica 慢。新 Shard 的數據需要完全從其他 Shard 拷貝，拷貝時間較長。

上面介紹了 Elasticsearch 數據層的架構，以及副本策略帶來的優勢和不足，下面簡單介紹了幾種不同形式的分布式數據系統架構。

分布式系統

基于本地文件系統的分布式系統

 

上圖中是一個基于本地磁盤存儲數據的分布式系統。Index 一共有 3 個 Shard，每個 Shard 除了 Primary Shard 外，還有一個 Replica Shard。

當 Node 3 機器宕機或磁盤損壞的時候，首先確認 P3 已經不可用，重新選舉 R3 位 Primary Shard，此 Shard 發生主備切換。然后重新找一臺機器 Node 7，在 Node 7 上重新啟動 P3 的新 Replica。

由于數據都會存在本地磁盤，此時需要將 Shard 3 的數據從 Node 6 上拷貝到 Node 7 上。

如果有 200G 數據，千兆網絡，拷貝完需要 1600 秒。如果沒有 Replica，則這 1600 秒內這些 Shard 就不能服務。

為了保證可靠性，就需要冗余 Shard，會導致更多的物理資源消耗。這種思想的另外一種表現形式是使用雙集群，集群級別做備份。

在這種架構中，如果你的數據是在其他存儲系統中生成的，比如 HDFS/HBase，那么你還需要一個數據傳輸系統，將準備好的數據分發到相應的機器上。

這種架構中為了保證可用性和可靠性，需要雙集群或者 Replica 才能用于生產環境，優勢和副作用在上面介紹 Elasticsearch 的時候已經介紹過了，這里就不贅述了。Elasticsearch 使用的就是這種架構方式。

基于分布式文件系統的分布式系統

針對第一種架構中的問題，另一種思路是：存儲和計算分離。 

第一種思路的問題根源是數據量大，拷貝數據耗時多，那么有沒有辦法可以不拷貝數據?

為了實現這個目的，一種思路是底層存儲層使用共享存儲，每個 Shard 只需要連接到一個分布式文件系統中的一個目錄/文件即可，Shard 中不含有數據，只含有計算部分。

相當于每個 Node 中只負責計算部分，存儲部分放在底層的另一個分布式文件系統中，比如 HDFS。

上圖中，Node 1 連接到第一個文件;Node 2連接到第二個文件;Node 3 連接到第三個文件。

當 Node 3 機器宕機后，只需要在 Node 4 機器上新建一個空的 Shard，然后構造一個新連接，連接到底層分布式文件系統的第三個文件即可，創建連接的速度是很快的，總耗時會非常短。

這種是一種典型的存儲和計算分離的架構，優勢有以下幾個方面：

• 在這種架構下，資源可以更加彈性，當存儲不夠的時候只需要擴容存儲系統的容量;當計算不夠的時候，只需要擴容計算部分容量。
• 存儲和計算是獨立管理的，資源管理粒度更小，管理更加精細化，浪費更少，結果就是總體成本可以更低。
• 負載更加突出，抗熱點能力更強。一般熱點問題基本都出現在計算部分，對于存儲和計算分離系統，計算部分由于沒有綁定數據，可以實時的擴容、縮容和遷移，當出現熱點的時候，可以第一時間將計算調度到新節點上。

這種架構同時也有一個不足：訪問分布式文件系統的性能可能不及訪問本地文件系統。

在上一代分布式文件系統中，這是一個比較明顯的問題，但是目前使用了各種用戶態協議棧后，這個差距已經越來越小了。HBase 使用的就是這種架構方式，Solr 也支持這種形式的架構。

總結

上述兩種架構，各有優勢和不足，對于某些架構中的不足或缺陷，思路不同，解決的方案也大相徑庭，但是思路跨度越大，收益一般也越大。

上面只是介紹了分布式數據(存儲/搜索/分析等等)系統在存儲層的兩種不同架構方式，希望能對大家有用。

但是分布式系統架構設計所涉及的內容廣，細節多，權衡點眾，如果大家對某些領域或者方面有興趣，也可以留言，后面再探討。