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

時間 2019-11-06

標籤拜託面試不要再問分佈式搜索引擎架構原理石杉的架構筆記欄目快樂工作简体版

原文原文鏈接

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）程序員

週一至週五早8點半！精品技術文章準時送上！面試

精品學習資料獲取通道，參見文末

目錄算法

（1）倒排索引究竟是啥？數據庫

（2）什麼叫分佈式搜索引擎？緩存

（3）ElasticSearch的數據結構性能優化

（4）Shard數據分片機制數據結構

（5）Replica多副本數據冗餘機制架構

（6）全文總結併發

「這篇文章，咱們來聊一下最近這一兩年行業內Java高級工程師面試的時候尤其常見的一個問題：談談你對分佈式搜索引擎的理解，聊聊他的架構原理？分佈式

不少同窗可能歷來沒接觸過這個東西，因此本文咱們就以如今最火最流行的Elasticsearch爲例，來聊一下分佈式搜索引擎的核心架構原理。」

（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架構經驗傾囊相授