拜託，面試請不要再問我分散式搜尋引擎的架構原理！【石杉的架構筆記】

分散式系統軟體架構 · 發表 2019-01-25 08:30:09

摘要：目錄（1）倒排索引到底是啥？（2）什麼叫分散式搜尋引擎？（3）ElasticSearch的資料結構（4）Shard資料分片機制（5）Replica多副本資料冗餘機制（6）全文總結 “ 這篇文章，我們來聊一下最近這一兩年行業內Java高階工程師面試的時候尤...

（1）倒排索引到底是啥？

要了解分散式搜尋引擎，先了解一下搜尋這個事兒吧，搜尋這個技術領域裡最入門級別的一個概念就是倒排索引。

我們先簡單說一下倒排索引是個什麼東西。

假如說你現在不用搜索引擎，單純使用資料庫來存放和搜尋一些資料，比如說放了一些論壇的帖子資料吧，那麼這個資料的格式大致如下：

很簡單吧，假設有一個id欄位標識了每個帖子資料，然後title欄位是帖子的標題，content欄位是帖子的內容。

那麼這個時候，比如我們要是用資料庫來進行搜尋包含“Java”這個關鍵字的所有帖子，大致SQL如下：

咱們姑且不論這個資料庫層面也有支援全文檢索的一些特殊索引型別，或者資料庫層面是怎麼執行的，這個不是本文討論的重點，你就看看資料庫的資料格式以及搜尋的方式就好了。

但是如果你通過搜尋引擎類的技術來存放帖子的內容，他是可以建立倒排索引的。

也就是說，你把上述的幾行資料放到搜尋引擎裡，這個倒排索引的資料大致看起來如下：

關鍵詞 id

Java [1, 2, 3]

語言 [1]

面試 [3]

資源 [2]

所謂的倒排索引，就是把你的資料內容先分詞，每句話分成一個一個的關鍵詞，然後記錄好每個關鍵詞對應出現在了哪些id標識的資料裡。

那麼你要搜尋包含“Java”關鍵詞的帖子，直接掃描這個倒排索引，在倒排索引裡找到“Java”這個關鍵詞對應的那些資料的id就好了。

然後你可以從其他地方根據這幾個id找到對應的資料就可以了，這個就是倒排索引的資料格式以及搜尋的方式，上面這種利用倒排索引查詢資料的方式，也被稱之為全文檢索。

（2）什麼叫做分散式搜尋引擎？

其實要知道什麼叫做分散式搜尋引擎，你首先得知道，假如我們就用一臺機器部署一個搜尋引擎系統，然後利用上述的那種倒排索引來儲存資料，同時支援一些全文檢索之類的搜尋功能，那麼會有什麼問題？

其實還是很簡單，假如說你現在要儲存1TB的資料，那麼放在一臺機器還是可以的。

但是如果你要儲存超過10TB，100TB，甚至1000TB的資料呢？你用一臺機器放的下嗎？

當然是放不下的了，你的機器磁碟空間是不夠的。

大家看一下下面的圖：

所以這個時候，你就得用分散式搜尋引擎了，也就是要使用多臺機器來部署搜尋引擎叢集。

比如說，假設你用的是Elasticsearch（後面簡寫為：ES）。

現在你總共有3TB的資料，那麼你搞3臺機器，每臺機器上部署一個ES程序，管理那臺機器上的1TB資料就可以了。

這樣不就可以把3TB的資料分散在3臺機器上來儲存了？這不就是索引資料的分散式儲存嗎？

而且，你在搜尋資料的時候，不就可以利用3臺機器來對分散式儲存後的資料進行搜尋了？每臺機器上的ES程序不都可以對一部分資料搜尋？這不就是分散式的搜尋？

是的，這就是所謂的分散式搜尋引擎：把大量的索引資料拆散成多塊，每臺機器放一部分，然後利用多臺機器對分散之後的資料進行搜尋，所有操作全部是分佈在多臺機器上進行，形成了完整的分散式的架構。

同樣，我們來看下面的圖，直觀的感受一下。

（3）Elasticsearch的資料結構

如果你要是使用Elasticsearch這種分散式搜尋引擎，必須要熟悉他的一些專業的技術名詞，描述他的一些資料結構。

比如說“index”這個東西，他是索引的意思，其實他有點類似於資料庫裡的一張表，大概對應表的那個概念。

比如你搞一個專門存放帖子的索引，然後他有id、title、content幾個field，這個field大致就是他的一個欄位。

然後還有一個概念，就是document，這個就代表了index中的一條資料。

下面就是一個document，這個document可以寫到index裡去，算是index裡的一條資料。

而且寫到es之後，這條資料的內容就會拆分為倒排索引的資料格式來儲存。

（4）Shard資料分片機制

那麼這個時候大家考慮一下，比如說你有一個index，專門存放論壇裡的帖子，現在論壇裡的帖子有1億，佔用了1TB的磁碟空間，這個還好說。

如果這個帖子有10億，100億，佔用了10TB、甚至100TB的磁碟空間呢？

那你這個index的資料還能在一臺機器上儲存嗎？答案明顯是不能的。

這個時候，你必須得支援這個index的資料分散式儲存在多臺機器上，利用多臺機器的磁碟空間來承載這麼大的資料量。

而且，需要保證每臺機器上對這個index儲存的資料量不要太大，因為控制單臺機器上這個index的資料量，可以保證他的搜尋效能更高。

所以這裡就引入了一個概念：Shard資料分片結構。每個index你都可以指定建立多少個shard，每個shard就是一個數據分片，會負責儲存這個index的一部分資料。

比如說index裡有3億帖子，佔據3TB資料。然後這個index你設定了3個shard。

那麼每個shard就可以包含一個1TB大小的資料分片，每個shard在叢集裡的一臺機器上，這樣就形成了利用3臺機器來分散式儲存一個index的資料的效果了。

大家看下面的圖：

現在index裡的3TB資料分散式儲存在了3臺機器上，每臺機器上有一個shard，每個shard負責管理這個index的其中1TB資料的分片。

而且，另外一個好處是，假設我們要對這個index的3TB資料執行一個搜尋，是不是可以傳送請求到3臺機器上去？

3臺機器上的shard直接可以分散式的並行對一部分資料進行搜尋，起到一個分散式搜尋的效果，大幅度提升海量資料的搜尋效能和吞吐量。

（5）Replica多副本資料冗餘機制

但是現在有一個問題，假如說3臺機器中的其中一臺宕機了，此時怎麼辦呢？

是不是這個index的3TB資料的1/3就丟失了？因為上面有1TB的資料分片沒了。

所以說，還需要為了實現高可用使用Replica多副本資料冗餘機制。

在Elasticsearch裡，就是支援對每個index設定一個replica數量的，也就是每個shard對應的replica副本的數量。

比如說你現在一個index有3個shard，你設定對每個shard做1個replica副本，那麼此時每個shard都會有一個replica shard。

這個初始的shard就是primary shard，而且primary shard和replica shard是絕對不會放在一臺機器上的，避免一臺機器宕機直接一個shard的副本也同時丟失了。

我們再來看下面的圖，感受一下：

在上述的replica機制下，每個primary shard都有一個replica shard在別的機器上，任何一臺機器宕機，都可以保證資料不會丟失，分散式搜尋引擎繼續可用。

Elasticsearch預設是支援每個index是5個primary shard，每個primary shard有1個replica shard作為副本。

（6）文末總結

好了，本文到這兒就結束了，再來給大夥簡單小結。

我們從搜尋引擎的倒排索引開始，到單機無法承載海量資料，再到分散式搜尋引擎的儲存和搜尋。

然後我們以優秀的分散式搜尋引擎ES為例，闡述了ES的資料結構，shard資料分片機制，replica多副本機制，解釋了一下分散式搜尋引擎的架構原理。

最後還是強調一下，在Java面試尤其是高階Java面試中，對於分散式搜尋引擎技術的考察越來越重，所以這塊技術的重要性，還是不容小覷的！

End

END

掃描下方二維碼，備註：“ 資料 ”，獲取更多“ 祕製 ” 精品學習資料

如有收穫，請幫忙轉發，您的鼓勵是作者最大的動力，謝謝！

一大波微服務、分散式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授