從Elasticsearch來看分佈式系統架構設計

點擊上方「匠心零度」,選擇「設爲星標數據庫

作積極的人,而不是積極廢人網絡

 

 

 

來源:https://dwz.cn/gPfuoLwo架構

分佈式系統類型多,涉及面很是廣,不一樣類型的系統有不一樣的特色,批量計算和實時計算就差異很是大。這篇文章中,重點會討論下分佈式數據系統的設計,好比分佈式存儲系統,分佈式搜索系統,分佈式分析系統等。併發

咱們先來簡單看下Elasticsearch的架構。app

Elasticsearch 集羣架構

Elasticsearch是一個很是著名的開源搜索和分析系統,目前被普遍應用於互聯網多種領域中,尤爲是如下三個領域特別突出。一是搜索領域,相對於solr,真正的後起之秀,成爲不少搜索系統的不二之選。二是Json文檔數據庫,相對於MongoDB,讀寫性能更佳,並且支持更豐富的地理位置查詢以及數字、文本的混合查詢等。三是時序數據分析處理,目前是日誌處理、監控數據的存儲、分析和可視化方面作得很是好,能夠說是該領域的引領者了。dom

Elasticsearch的詳細介紹能夠到官網查看。咱們先來看一下Elasticsearch中幾個關鍵概念:分佈式

  • 節點(Node):物理概念,一個運行的Elasticearch實例,通常是一臺機器上的一個進程。性能

  • 索引(Index),邏輯概念,包括配置信息mapping和倒排正排數據文件,一個索引的數據文件可能會分佈於一臺機器,也有可能分佈於多臺機器。索引的另一層意思是倒排索引文件。ui

  • 分片(Shard):爲了支持更大量的數據,索引通常會按某個維度分紅多個部分,每一個部分就是一個分片,分片被節點(Node)管理。一個節點(Node)通常會管理多個分片,這些分片多是屬於同一份索引,也有可能屬於不一樣索引,可是爲了可靠性和可用性,同一個索引的分片儘可能會分佈在不一樣節點(Node)上。分片有兩種,主分片和副本分片。spa

  • 副本(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支持上述兩種方式:

1.混合部署(左圖)

  • 默認方式。

  • 不考慮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保持鏈接,而一個系統的鏈接數是有上限的,這樣鏈接數就會限制集羣規模。

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

2.分層部署(右圖):

  • 經過配置能夠隔離開Node。

  • 設置部分Node爲Transport Node,專門用來作請求轉發和結果合併。

  • 其餘Node能夠設置爲DataNode,專門用來處理數據。

  • 缺點是上手複雜,須要提早設置好Transport的數量,且數量和Data Node、流量等相關,不然要麼資源閒置,要麼機器被打爆。

  • 好處就是角色相互獨立,不會相互影響,通常Transport Node的流量是平均分配的,不多出現單臺機器的CPU或流量被打滿的狀況,而DataNode因爲處理數據,很容易出現單機資源被佔滿,好比CPU,網絡,磁盤等。獨立開後,DataNode若是出了故障只是影響單節點的數據處理,不會影響其餘節點的請求,影響限制在最小的範圍內。

  • 角色獨立後,只須要Transport Node鏈接全部的DataNode,而DataNode則不須要和其餘DataNode有鏈接。一個集羣中DataNode的數量遠大於Transport Node,這樣集羣的規模能夠更大。另外,還能夠經過分組,使Transport Node只鏈接固定分組的DataNode,這樣Elasticsearch的鏈接數問題就完全解決了。

  • 能夠支持熱更新:先一臺一臺的升級DataNode,升級完成後再升級Transport Node,整個過程當中,能夠作到讓用戶無感知。

上面介紹了Elasticsearch的部署層架構,不一樣的部署方式適合不一樣場景,須要根據本身的需求選擇適合的方式。

Elasticsearch 數據層架構

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

數據存儲

Elasticsearch的Index和meta,目前支持存儲在本地文件系統中,同時支持niofs,mmap,simplefs,smb等不一樣加載方式,性能最好的是直接將索引LOCK進內存的MMap方式。默認,Elasticsearch會自動選擇加載方式,另外能夠本身在配置文件中配置。這裏有幾個細節,具體能夠看官方文檔。

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

副本(Replica)

能夠爲每個Index設置一個配置項:副本(Replicda)數,若是設置副本數爲2,那麼就會有3個Shard,其中一個是PrimaryShard,其他兩個是ReplicaShard,這三個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,在Node7 上從新啓動P3的新Replica。因爲數據都會存在本地磁盤,此時須要將Shard 3的數據從Node 6上拷貝到Node7上。若是有200G數據,千兆網絡,拷貝完須要1600秒。若是沒有replica,則這1600秒內這些Shard就不能服務。

爲了保證可靠性,就須要冗餘Shard,會致使更多的物理資源消耗。

這種思想的另一種表現形式是使用雙集羣,集羣級別作備份。

在這種架構中,若是你的數據是在其餘存儲系統中生成的,好比HDFS/HBase,那麼你還須要一個數據傳輸系統,將準備好的數據分發到相應的機器上。

這種架構中爲了保證可用性和可靠性,須要雙集羣或者Replica才能用於生產環境,優點和反作用在上面介紹Elasticsearch的時候已經介紹過了,這裏就就不贅述了。

Elasticsearch使用的就是這種架構方式。

第二種:基於分佈式文件系統的分佈式系統(共享存儲)

 

 

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

第一種思路的問題根源是數據量大,拷貝數據耗時多,那麼有沒有辦法能夠不拷貝數據?爲了實現這個目的,一種思路是底層存儲層使用共享存儲,每一個Shard只須要鏈接到一個分佈式文件系統中的一個目錄/文件便可,Shard中不含有數據,只含有計算部分。至關於每一個Node中只負責計算部分,存儲部分放在底層的另外一個分佈式文件系統中,好比HDFS。

上圖中,Node 1 鏈接到第一個文件;Node 2鏈接到第二個文件;Node3鏈接到第三個文件。當Node 3機器宕機後,只須要在Node 4機器上新建一個空的Shard,而後構造一個新鏈接,鏈接到底層分佈式文件系統的第三個文件便可,建立鏈接的速度是很快的,總耗時會很是短。

這種是一種典型的存儲和計算分離的架構,優點有如下幾個方面:

  • 在這種架構下,資源能夠更加彈性,當存儲不夠的時候只須要擴容存儲系統的容量;當計算不夠的時候,只須要擴容計算部分容量。

  • 存儲和計算是獨立管理的,資源管理粒度更小,管理更加精細化,浪費更少,結果就是整體成本能夠更低。

  • 負載更加突出,抗熱點能力更強。通常熱點問題基本都出如今計算部分,對於存儲和計算分離系統,計算部分因爲沒有綁定數據,能夠實時的擴容、縮容和遷移,當出現熱點的時候,能夠第一時間將計算調度到新節點上。

這種架構同時也有一個不足:訪問分佈式文件系統的性能可能不及訪問本地文件系統。在上一代分佈式文件系統中,這是一個比較明顯的問題,可是目前使用了各類用戶態協議棧後,這個差距已經愈來愈小了。HBase使用的就是這種架構方式。
Solr也支持這種形式的架構。

總結

上述兩種架構,各有優點和不足,對於某些架構中的不足或缺陷,思路不一樣,解決的方案也截然不同,可是思路跨度越大,收益通常也越大。

上面只是介紹了分佈式數據(存儲/搜索/分析等等)系統在存儲層的兩種不一樣架構方式,但願能對你們有用。可是分佈式系統架構設計所涉及的內容廣,細節多,權衡點衆,若是你們對某些領域或者方面有興趣,也能夠留言,後面再探討。

相關文章
相關標籤/搜索