分布式搜索引擎Elasticsearch的架構(gòu)分析

時間：2021-09-23 16:03:33

關鍵字： search 分布式 ic

手機看文章

掃描二維碼
隨時隨地手機看文章

[導讀]一、寫在前面?ES（Elasticsearch下文統(tǒng)一稱為ES）越來越多的企業(yè)在業(yè)務場景是使用ES存儲自己的非結(jié)構(gòu)化數(shù)據(jù)，例如電商業(yè)務實現(xiàn)商品站內(nèi)搜索，數(shù)據(jù)指標分析，日志分析等，ES作為傳統(tǒng)關系型數(shù)據(jù)庫的補充，提供了關系型數(shù)據(jù)庫不具備的一些能力。ES最先進入大眾視野的是其能夠?qū)崿F(xiàn)...

一、寫在前面

ES（Elastic search下文統(tǒng)一稱為ES）越來越多的企業(yè)在業(yè)務場景是使用ES存儲自己的非結(jié)構(gòu)化數(shù)據(jù)，例如電商業(yè)務實現(xiàn)商品站內(nèi)搜索，數(shù)據(jù)指標分析，日志分析等，ES作為傳統(tǒng)關系型數(shù)據(jù)庫的補充，提供了關系型數(shù)據(jù)庫不具備的一些能力。

ES最先進入大眾視野的是其能夠?qū)崿F(xiàn)全文搜索的能力，也是由于基于Lucene的實現(xiàn)，內(nèi)部有一種倒排索引的數(shù)據(jù)結(jié)構(gòu)。

本文作者將介紹ES的分布式架構(gòu)，以及ES的存儲索引機制，本文不會詳細介紹ES的API，會從整體架構(gòu)層面進行分析，后續(xù)作者會有其他文章對ES的使用進行介紹。

二、什么是倒排索引

要講明白什么是倒排索引，首先我們先梳理下什么索引，比如一本書，書的目錄頁，有章節(jié)，章節(jié)名稱，我們想看哪個章節(jié)，我們通過目錄頁，查到對應章節(jié)和頁碼，就能定位到具體的章節(jié)內(nèi)容，通過目錄頁的章節(jié)名稱查到章節(jié)的頁碼，進而看到章節(jié)內(nèi)容，這個過程就是一個索引的過程，那么什么是倒排索引呢？

比如查詢《java編程思想》這本書的文章，翻開書本可以看到目錄頁，記錄這個章節(jié)名字和章節(jié)地址頁碼，通過查詢章節(jié)名字“繼承”可以定位到“繼承”這篇章節(jié)的具體地址，查看到文章的內(nèi)容，我們可以看到文章內(nèi)容中包含很多“對象”這個詞。

那么如果我們要在這本書中查詢所有包含有“對象”這個詞的文章，那該怎么辦呢？

按照現(xiàn)在的索引方式無疑大海撈針，假設我們有一個“對象”--→文章的映射關系，不就可以了嗎？類似這樣的反向建立映射關系的就叫倒排索引。

如圖1所示，將文章進行分詞后得到關鍵詞，在根據(jù)關鍵詞建立倒排索引，關鍵詞構(gòu)建成一個詞典，詞典中存放著一個個詞條（關鍵詞），每個關鍵詞都有一個列表與其對應，這個列表就是倒排表，存放的是章節(jié)文檔編號和詞頻等信息，倒排列表中的每個元素就是一個倒排項，最后可以看到，整個倒排索引就像一本新華字典，所有單詞的倒排列表往往順序地存儲在磁盤的某個文件里，這個文件被稱之為倒排文件。

（圖1）

詞典和倒排文件是Lucene的兩種基本數(shù)據(jù)結(jié)構(gòu)，但是存儲方式不同，詞典在內(nèi)存中存儲，倒排文件在磁盤上。本文不會去介紹分詞，tf-idf，BM25，向量空間相似度等構(gòu)建倒排索引和查詢倒排索引所用到的技術(shù)，讀者只需要對倒排索引有個基本的認識即可。

三、ES的集群架構(gòu)

1. 集群節(jié)點

一個ES集群可以有多個節(jié)點構(gòu)成，一個節(jié)點就是一個ES服務實例，通過配置集群名稱cluster.name加入集群。那么節(jié)點是如何通過配置相同的集群名稱加入集群的呢？要搞明白這個問題，我們必須先搞清楚ES集群中節(jié)點的角色。

ES中節(jié)點有角色的區(qū)分的，通過配置文件conf/elasticsearch.yml中配置以下配置進行角色的設定。

node.master: true/falsenode.data: true/false

集群中單個節(jié)點既可以是候選主節(jié)點也可以是數(shù)據(jù)節(jié)點，通過上面的配置可以進行兩兩組合形成四大分類：

（1）僅為候選主節(jié)點
（2）既是候選主節(jié)點也是數(shù)據(jù)節(jié)點
（3）僅為數(shù)據(jù)節(jié)點
（4）既不是候選主節(jié)點也不是數(shù)據(jù)節(jié)點

候選主節(jié)點：只有是候選主節(jié)點才可以參與選舉投票，也只有候選主節(jié)點可以被選舉為主節(jié)點。

主節(jié)點：負責索引的添加、刪除，跟蹤哪些節(jié)點是群集的一部分，對分片進行分配、收集集群中各節(jié)點的狀態(tài)等，穩(wěn)定的主節(jié)點對集群的健康是非常重要。

數(shù)據(jù)節(jié)點：負責對數(shù)據(jù)的增、刪、改、查、聚合等操作，數(shù)據(jù)的查詢和存儲都是由數(shù)據(jù)節(jié)點負責，對機器的CPU，IO以及內(nèi)存的要求比較高，一般選擇高配置的機器作為數(shù)據(jù)節(jié)點。

此外還有一種節(jié)點角色叫做協(xié)調(diào)節(jié)點，其本身不是通過設置來分配的，用戶的請求可以隨機發(fā)往任何一個節(jié)點，并由該節(jié)點負責分發(fā)請求、收集結(jié)果等操作，而不需要主節(jié)點轉(zhuǎn)發(fā)。這種節(jié)點可稱之為協(xié)調(diào)節(jié)點，集群中的任何節(jié)點都可以充當協(xié)調(diào)節(jié)點的角色。每個節(jié)點之間都會保持聯(lián)系。

（圖2）

2. 發(fā)現(xiàn)機制

前文說到通過設置一個集群名稱，節(jié)點就可以加入集群，那么ES是如何做到這一點的呢？

這里就要講一講ES特殊的發(fā)現(xiàn)機制ZenDiscovery。

ZenDiscovery是ES的內(nèi)置發(fā)現(xiàn)機制，提供單播和多播兩種發(fā)現(xiàn)方式，主要職責是集群中節(jié)點的發(fā)現(xiàn)以及選舉Master節(jié)點。

多播也叫組播，指一個節(jié)點可以向多臺機器發(fā)送請求。生產(chǎn)環(huán)境中ES不建議使用這種方式，對于一個大規(guī)模的集群，組播會產(chǎn)生大量不必要的通信。

單播，當一個節(jié)點加入一個現(xiàn)有集群，或者組建一個新的集群時，請求發(fā)送到一臺機器。當一個節(jié)點聯(lián)系到單播列表中的成員時，它就會得到整個集群所有節(jié)點的狀態(tài)，然后它會聯(lián)系Master節(jié)點，并加入集群。

只有在同一臺機器上運行的節(jié)點才會自動組成集群。ES 默認被配置為使用單播發(fā)現(xiàn)，單播列表不需要包含集群中的所有節(jié)點，它只是需要足夠的節(jié)點，當一個新節(jié)點聯(lián)系上其中一個并且通信就可以了。如果你使用 Master 候選節(jié)點作為單播列表，你只要列出三個就可以了。

這個配置在 elasticsearch.yml 文件中：

discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]

集群信息收集階段采用了 Gossip 協(xié)議，上面配置的就相當于一個seed nodes，Gossip協(xié)議這里就不多做贅述了。

ES官方建議unicast.hosts配置為所有的候選主節(jié)點，ZenDiscovery 會每隔ping_interval（配置項）ping一次，每次超時時間是discovery.zen.ping_timeout（配置項），3次(ping_retries配置項)ping失敗則認為節(jié)點宕機，宕機的情況下會觸發(fā)failover，會進行分片重分配、復制等操作。

如果宕機的節(jié)點不是Master，則Master會更新集群的元信息，Master節(jié)點將最新的集群元信息發(fā)布出去，給其他節(jié)點，其他節(jié)點回復Ack，Master節(jié)點收到discovery.zen.minimum_master_nodes的值-1個候選主節(jié)點的回復，則發(fā)送Apply消息給其他節(jié)點，集群狀態(tài)更新完畢。如果宕機的節(jié)點是Master，則其他的候選主節(jié)點開始Master節(jié)點的選舉流程。

2.1 選主

Master的選主過程中要確保只有一個master，ES通過一個參數(shù)quorum的代表多數(shù)派閾值，保證選舉出的master被至少quorum個的候選主節(jié)點認可，以此來保證只有一個master。

選主的發(fā)起由候選主節(jié)點發(fā)起，當前候選主節(jié)點發(fā)現(xiàn)自己不是master節(jié)點，并且通過ping其他節(jié)點發(fā)現(xiàn)無法聯(lián)系到主節(jié)點，并且包括自己在內(nèi)已經(jīng)有超過minimum_master_nodes個節(jié)點無法聯(lián)系到主節(jié)點，那么這個時候則發(fā)起選主。

選主流程圖

（圖3）

選主的時候按照集群節(jié)點的參數(shù) 排序。stateVersion從大到小排序，以便選出集群元信息較新的節(jié)點作為Master，id從小到大排序，避免在stateVersion相同時發(fā)生分票無法選出 Master。

排序后第一個節(jié)點即為Master節(jié)點。當一個候選主節(jié)點發(fā)起一次選舉時，它會按照上述排序策略選出一個它認為的Master。

2.2 腦裂

提到分布式系統(tǒng)選主，不可避免的會提到腦裂這樣一個現(xiàn)象，什么是腦裂呢？如果集群中選舉出多個Master節(jié)點，使得數(shù)據(jù)更新時出現(xiàn)不一致，這種現(xiàn)象稱之為腦裂。

簡而言之集群中不同的節(jié)點對于 Master的選擇出現(xiàn)了分歧，出現(xiàn)了多個Master競爭。

一般而言腦裂問題可能有以下幾個原因造成：

網(wǎng)絡問題：集群間的網(wǎng)絡延遲導致一些節(jié)點訪問不到Master，認為Master 掛掉了，而master其實并沒有宕機，而選舉出了新的Master，并對Master上的分片和副本標紅，分配新的主分片。
節(jié)點負載：主節(jié)點的角色既為Master又為Data，訪問量較大時可能會導致 ES 停止響應（假死狀態(tài)）造成大面積延遲，此時其他節(jié)點得不到主節(jié)點的響應認為主節(jié)點掛掉了，會重新選取主節(jié)點。
內(nèi)存回收：主節(jié)點的角色既為Master又為Data，當Data節(jié)點上的ES進程占用的內(nèi)存較大，引發(fā)JVM的大規(guī)模內(nèi)存回收，造成ES進程失去響應。

如何避免腦裂：我們可以基于上述原因，做出優(yōu)化措施：

適當調(diào)大響應超時時間，減少誤判。通過參數(shù) discovery.zen.ping_timeout 設置節(jié)點ping超時時間，默認為 3s，可以適當調(diào)大。
選舉觸發(fā)，我們需要在候選節(jié)點的配置文件中設置參數(shù) discovery.zen.munimum_master_nodes 的值。這個參數(shù)表示在選舉主節(jié)點時需要參與選舉的候選主節(jié)點的節(jié)點數(shù)，默認值是 1，官方建議取值(master_eligibel_nodes/2) 1，其中 master_eligibel_nodes 為候選主節(jié)點的個數(shù)。這樣做既能防止腦裂現(xiàn)象的發(fā)生，也能最大限度地提升集群的高可用性，因為只要不少于 discovery.zen.munimum_master_nodes 個候選節(jié)點存活，選舉工作就能正常進行。當小于這個值的時候，無法觸發(fā)選舉行為，集群無法使用，不會造成分片混亂的情況。
角色分離，即是上面我們提到的候選主節(jié)點和數(shù)據(jù)節(jié)點進行角色分離，這樣可以減輕主節(jié)點的負擔，防止主節(jié)點的假死狀態(tài)發(fā)生，減少對主節(jié)點宕機的誤判。

四、索引如何寫入的

1. 寫索引原理

1.1 分片

ES支持PB級全文搜索，通常我們數(shù)據(jù)量很大的時候，查詢性能都會越來越慢，我們能想到的一個方式的將數(shù)據(jù)分散到不同的地方存儲，ES也是如此，ES通過水平拆分的方式將一個索引上的數(shù)據(jù)拆分出來分配到不同的數(shù)據(jù)塊上，拆分出來的數(shù)據(jù)庫塊稱之為一個分片Shard，很像MySQL的分庫分表。

不同的主分片分布在不同的節(jié)點上，那么在多分片的索引中數(shù)據(jù)應該被寫入哪里？肯定不能隨機寫，否則查詢的時候就無法快速檢索到對應的數(shù)據(jù)了，這需要有一個路由策略來確定具體寫入哪一個分片中，怎么路由我們下文會介紹。在創(chuàng)建索引的時候需要指定分片的數(shù)量，并且分片的數(shù)量一旦確定就不能修改。

1.2 副本

副本就是對分片的復制，每個主分片都有一個或多個副本分片，當主分片異常時，副本可以提供數(shù)據(jù)的查詢等操作。主分片和對應的副本分片是不會在同一個節(jié)點上的，避免數(shù)據(jù)的丟失，當一個節(jié)點宕機的時候，還可以通過副本查詢到數(shù)據(jù)，副本分片數(shù)的最大值是 N-1（其中 N 為節(jié)點數(shù)）。

對doc的新建、索引和刪除請求都是寫操作，這些寫操作是必須在主分片上完成，然后才能被復制到對應的副本上。ES為了提高寫入的能力這個過程是并發(fā)寫的，同時為了解決并發(fā)寫的過程中數(shù)據(jù)沖突的問題，ES通過樂觀鎖的方式控制，每個文檔都有一個 _version號，當文檔被修改時版本號遞增。

一旦所有的副本分片都報告寫成功才會向協(xié)調(diào)節(jié)點報告成功，協(xié)調(diào)節(jié)點向客戶端報告成功。

（圖4）

1.3 Elasticsearch 的寫索引流程

上面提到了寫索引是只能寫在主分片上，然后同步到副本分片，那么如圖4所示，這里有四個主分片分別是S0、S1、S2、S3，一條數(shù)據(jù)是根據(jù)什么策略寫到指定的分片上呢？這條索引數(shù)據(jù)為什么被寫到S0上而不寫到 S1 或 S2 上？這個過程是根據(jù)下面這個公式?jīng)Q定的。

shard = hash(routing) % number_of_primary_shards

以上公式的值是在0到number_of_primary_shards-1之間的余數(shù)，也就是數(shù)據(jù)檔所在分片的位置。routing通過Hash函數(shù)生成一個數(shù)字，然后這個數(shù)字再除以number_of_primary_shards（主分片的數(shù)量）后得到余數(shù)。routing是一個可變值，默認是文檔的_id ，也可以設置成一個自定義的值。

在一個寫請求被發(fā)送到某個節(jié)點后，該節(jié)點按照前文所述，會充當協(xié)調(diào)節(jié)點，會根據(jù)路由公式計算出寫哪個分片，當前節(jié)點有所有其他節(jié)點的分片信息，如果發(fā)現(xiàn)對應的分片是在其他節(jié)點上，再將請求轉(zhuǎn)發(fā)到該分片的主分片節(jié)點上。

在ES集群中每個節(jié)點都通過上面的公式知道數(shù)據(jù)的在集群中的存放位置，所以每個節(jié)點都有接收讀寫請求的能力。

那么為什么在創(chuàng)建索引的時候就確定好主分片的數(shù)量，并且不可修改？因為如果數(shù)量變化了，那么所有之前路由計算的值都會無效，數(shù)據(jù)也就再也找不到了。

（圖5）

如上圖5所示，當前一個數(shù)據(jù)通過路由計算公式得到的值是 shard=hash(routing)%4=0，則具體流程如下：

（1）數(shù)據(jù)寫請求發(fā)送到 node1 節(jié)點，通過路由計算得到值為1，那么對應的數(shù)據(jù)會應該在主分片S1上。

（2）node1節(jié)點將請求轉(zhuǎn)發(fā)到 S1 主分片所在的節(jié)點node2，node2 接受請求并寫入到磁盤。

（3）并發(fā)將數(shù)據(jù)復制到三個副本分片R1上，其中通過樂觀并發(fā)控制數(shù)據(jù)的沖突。一旦所有的副本分片都報告成功，則節(jié)點 node2將向node1節(jié)點報告成功，然后node1節(jié)點向客戶端報告成功。

這種模式下，只要有副本在，寫入延時最小也是兩次單分片的寫入耗時總和，效率會較低，但是這樣的好處也很明顯，避免寫入后單個機器硬件故障導致數(shù)據(jù)丟失，在數(shù)據(jù)完整性和性能方面，一般都是優(yōu)先選擇數(shù)據(jù)，除非一些允許丟數(shù)據(jù)的特殊場景。

在ES里為了減少磁盤IO保證讀寫性能，一般是每隔一段時間（比如30分鐘）才會把數(shù)據(jù)寫入磁盤持久化，對于寫入內(nèi)存，但還未flush到磁盤的數(shù)據(jù)，如果發(fā)生機器宕機或者掉電，那么內(nèi)存中的數(shù)據(jù)也會丟失，這時候如何保證？

對于這種問題，ES借鑒數(shù)據(jù)庫中的處理方式，增加CommitLog模塊，在ES中叫transLog，在下面的ES存儲原理中會介紹。

2. 存儲原理

上面介紹了在ES內(nèi)部的寫索引處理流程，數(shù)據(jù)在寫入到分片和副本上后，目前數(shù)據(jù)在內(nèi)存中，要確保數(shù)據(jù)在斷電后不丟失，還需要持久化到磁盤上。

我們知道ES是基于Lucene實現(xiàn)的，內(nèi)部是通過Lucene完成的索引的創(chuàng)建寫入和搜索查詢，Lucene 工作原理如下圖所示，當新添加一片文檔時，Lucene進行分詞等預處理，然后將文檔索引寫入內(nèi)存中，并將本次操作寫入事務日志（transLog），transLog類似于mysql的binlog，用于宕機后內(nèi)存數(shù)據(jù)的恢復，保存未持久化數(shù)據(jù)的操作日志。

默認情況下，Lucene每隔1s(refresh_interval配置項)將內(nèi)存中的數(shù)據(jù)刷新到文件系統(tǒng)緩存中，稱為一個segment（段）。一旦刷入文件系統(tǒng)緩存，segment才可以被用于檢索，在這之前是無法被檢索的。

因此refresh_interval決定了ES數(shù)據(jù)的實時性，因此說ES是一個準實時的系統(tǒng)。segment 在磁盤中是不可修改的，因此避免了磁盤的隨機寫，所有的隨機寫都在內(nèi)存中進行。隨著時間的推移，segment越來越多，默認情況下，Lucene每隔30min或segment 空間大于512M，將緩存中的segment持久化落盤，稱為一個commit point，此時刪掉對應的transLog。

當我們在進行寫操作的測試的時候，可以通過手動刷新來保障數(shù)據(jù)能夠被及時檢索到，但是不要在生產(chǎn)環(huán)境下每次索引一個文檔都去手動刷新，刷新操作會有一定的性能開銷。一般業(yè)務場景中并不都需要每秒刷新。

可以通過在 Settings 中調(diào)大 refresh_interval = "30s" 的值，來降低每個索引的刷新頻率，設值時需要注意后面帶上時間單位，否則默認是毫秒。當 refresh_interval=-1 時表示關閉索引的自動刷新。

（圖6）

索引文件分段存儲并且不可修改，那么新增、更新和刪除如何處理呢？

新增，新增很好處理，由于數(shù)據(jù)是新的，所以只需要對當前文檔新增一個段就可以了。
刪除，由于不可修改，所以對于刪除操作，不會把文檔從舊的段中移除而是通過新增一個 .del 文件，文件中會列出這些被刪除文檔的段信息，這個被標記刪除的文檔仍然可以被查詢匹配到，但它會在最終結(jié)果被返回前從結(jié)果集中移除。

更新，不能修改舊的段來進行文檔的更新，其實更新相當于是刪除和新增這兩個動作組成。會將舊的文檔在 .del 文件中標記刪除，然后文檔的新版本中被索引到一個新的段?？赡軆蓚€版本的文檔都會被一個查詢匹配到，但被刪除的那個舊版本文檔在結(jié)果集返回前就會被移除。

segment被設定為不可修改具有一定的優(yōu)勢也有一定的缺點。

優(yōu)點：

不需要鎖。如果你從來不更新索引，你就不需要擔心多進程同時修改數(shù)據(jù)的問題。
一旦索引被讀入內(nèi)核的文件系統(tǒng)緩存，便會留在哪里，由于其不變性。只要文件系統(tǒng)緩存中還有足夠的空間，那么大部分讀請求會直接請求內(nèi)存，而不會命中磁盤。這提供了很大的性能提升.
其它緩存(像 Filter 緩存)，在索引的生命周期內(nèi)始終有效。它們不需要在每次數(shù)據(jù)改變時被重建，因為數(shù)據(jù)不會變化。
寫入單個大的倒排索引允許數(shù)據(jù)被壓縮，減少磁盤 I/O 和需要被緩存到內(nèi)存的索引的使用量。

缺點：

當對舊數(shù)據(jù)進行刪除時，舊數(shù)據(jù)不會馬上被刪除，而是在 .del 文件中被標記為刪除。而舊數(shù)據(jù)只能等到段更新時才能被移除，這樣會造成大量的空間浪費。
若有一條數(shù)據(jù)頻繁的更新，每次更新都是新增新的，標記舊的，則會有大量的空間浪費。
每次新增數(shù)據(jù)時都需要新增一個段來存儲數(shù)據(jù)。當段的數(shù)量太多時，對服務器的資源例如文件句柄的消耗會非常大。
在查詢的結(jié)果中包含所有的結(jié)果集，需要排除被標記刪除的舊數(shù)據(jù)，這增加了查詢的負擔。