歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）
週一至週五早8點半！精品技術文章準時送上！
精品學習資料獲取通道，參見文末
目錄
（1）倒排索引到底是啥？
（2）什麼叫分散式搜尋引擎？
（3）ElasticSearch的資料結構
（4）Shard資料分片機制
（5）Replica多副本資料冗餘機制
（6）全文總結
“ 這篇文章，我們來聊一下最近這一兩年行業內Java高階工程師面試的時候尤為常見的一個問題：談談你對分散式搜尋引擎的理解，聊聊他的架構原理？
很多同學可能從來沒接觸過這個東西，所以本文我們就以現在最火最流行的Elasticsearch為例，來聊一下分散式搜尋引擎的核心架構原理。”
（1）倒排索引到底是啥？
要了解分散式搜尋引擎，先了解一下搜尋這個事兒吧，搜尋這個技術領域裡最入門級別的一個概念就是倒排索引。
我們先簡單說一下倒排索引是個什麼東西。
假如說你現在不用搜尋引擎，單純使用資料庫來存放和搜尋一些資料，比如說放了一些論壇的帖子資料吧，那麼這個資料的格式大致如下：
那麼這個時候，比如我們要是用資料庫來進行搜尋包含“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架構經驗傾囊相授
推薦閱讀：
2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
9、【坑爹呀！】最終一致性分散式事務如何保障實際生產中99.99%高可用？
11、【眼前一亮！】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上？
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
18、大白話聊聊Java併發面試問題之volatile到底是什麼？
19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能？
20、大白話聊聊Java併發面試問題之談談你對AQS的理解？
21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？
22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
23、網際網路公司的面試官是如何360°無死角考察候選人的？（上篇）
24、網際網路公司面試官是如何360°無死角考察候選人的？（下篇）
25、Java進階面試系列之一：哥們，你們的系統架構中為什麼要引入訊息中介軟體？
26、【Java進階面試系列之二】：哥們，那你說說系統架構引入訊息中介軟體有什麼缺點？
27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷
28、【Java進階面試系列之三】哥們，訊息中介軟體在你們專案裡是如何落地的？
29、【Java進階面試系列之四】扎心！線上服務當機時，如何保證資料100%不丟失？
30、一次JVM FullGC的背後，竟隱藏著驚心動魄的線上生產事故！
31、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？
32、【Java進階面試系列之五】訊息中介軟體叢集崩潰，如何保證百萬生產資料不丟失？
33、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（上）？
34、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？
35、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（下）？
37、億級流量系統架構之如何保證百億流量下的資料一致性（上）
38、億級流量系統架構之如何保證百億流量下的資料一致性（中）？
39、億級流量系統架構之如何保證百億流量下的資料一致性（下）？
40、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（1）
41、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（2）
42、面試大殺器：訊息中介軟體如何實現消費吞吐量的百倍優化？
43、高併發場景下，如何保證生產者投遞到訊息中介軟體的訊息不丟失？
45、從團隊自研的百萬併發中介軟體系統的核心設計看Java併發效能優化
46、【非廣告，純乾貨】英語差的程式設計師如何才能無障礙閱讀官方文件？
47、如果20萬使用者同時訪問一個熱點快取，如何優化你的快取架構？
48、【非廣告，純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT？
作者：石杉的架構筆記 連結：juejin.im/post/5c263a… 來源：掘金 著作權歸作者所有，轉載請聯絡作者獲得授權！