分佈式搜索引擎-ES的分佈式架構原理能說一下麼?

分佈式搜索引擎的面試連環炮

面試題

es 的分佈式架構原理能說一下麼(es 是如何實現分佈式的啊)?

面試官心理分析

在搜索這塊,lucene 是最流行的搜索庫。幾年前業內一般都問,你瞭解 lucene 嗎?你知道倒排索引的原理嗎?現在早已經 out 了,因爲現在很多項目都是直接用基於 lucene 的分佈式搜索引擎—— ElasticSearch,簡稱爲 es。

而現在分佈式搜索基本已經成爲大部分互聯網行業的 Java 系統的標配,其中尤爲流行的就是 es,前幾年 es 沒火的時候,大家一般用 solr。但是這兩年基本大部分企業和項目都開始轉向 es 了。

所以互聯網面試,肯定會跟你聊聊分佈式搜索引擎,也就一定會聊聊 es,如果你確實不知道,那你真的就 out 了。

如果面試官問你第一個問題,確實一般都會問你 es 的分佈式架構設計能介紹一下麼?就看看你對分佈式搜索引擎架構的一個基本理解。

面試題剖析

01_elasticsearch分佈式架構原理

elasticsearch設計的理念就是分佈式搜索引擎,底層其實還是基於lucene的。

核心思想就是在多臺機器上啓動多個es進程實例,組成了一個es集羣。

es中存儲數據的基本單位是索引,比如說你現在要在es中存儲一些訂單數據,你就應該在es中創建一個索引,order_idx,所有的訂單數據就都寫到這個索引裏面去,一個索引差不多就是相當於是mysql裏的一張表。

index -> type -> mapping -> document -> field。
  • index:index相當於mysql裏裏的一張表。
  • type:type沒法跟mysql裏去對比,一個index裏可以有多個type,每個type的彼此都是差不多的,但是有一些略微的區別。假設有一個index ,是訂單索引,裏面專門是放訂單數據的。就好比說你在mysql中建表,有些訂單是實物商品的訂單,一件衣服,一雙鞋子;有些訂單是虛擬商品的訂單,某些遊戲點卡,話費充值。就兩個訂單大部分片段是一樣的,但是少部分分段可能有略微的一些區別。所以就會在訂單索引裏,建兩個類型,一個是實物商品訂單類型,一個是虛擬商品訂單類型,這兩個類型大部分都是相同的,少部分是不一樣的。很多情況下,一個index裏可能就一個類型,但是確實如果說是一個index裏有多個type的情況(注意,mapping types這個概念在ElasticSearch 7.X已被完全刪除,詳細說明可以參考官方文檔),您可以認爲index是一個類別的表,具體的每個類型代表mysql中的一個表。
  • mapping :每個type有一個映射,如果您認爲一個type是具體的一個表,index就代表多個type同屬於的一個類型,而map就是這個類型的表結構定義,你在mysql中創建一個表,肯定是要定義表結構的,裏面有什麼區別,每個分開是什麼類型。
  • document :實際上你往索引裏的一個類型裏面寫的一條數據,叫做一條文檔,一條文檔就代表了mysql中某個表裏的一行,每個文檔有多個字段,每個字段就代表了這個文檔中的一個值。

 

接着你搞一個索引,這個索引可以拆分成多個shard,每個shard存儲部分數據。

接着就是這個shard的數據實際是有多個備份,就是說每個shard都有一個primary shard,負責寫入數據,但是還有幾個replica shard。primary shard寫入數據之後,會將數據同步到其他幾個replica shard上去。

通過這個replica的方案,每個shard的數據都有多個備份,如果某個機器宕機了,沒關係啊,還有別的數據副本在別的機器上呢。高可用了吧。

es集羣多個節點,會自動選舉一個節點爲master節點,這個master節點其實就是幹一些管理的工作的,比如維護索引元數據拉,負責切換primary shard和replica shard身份拉,之類的。

要是master節點宕機了,那麼會重新選舉一個節點爲master節點。

如果是非master節點宕機了,那麼會由master節點,讓那個宕機節點上的primary shard的身份轉移到其他機器上的replica shard。過了一段時間,你要是修復了那個宕機機器,重啓了之後,master節點會控制將缺失的replica shard分配過去,同步後續修改的數據之類的,讓集羣恢復正常。

其實上述就是elasticsearch作爲一個分佈式搜索引擎最基本的一個架構設計

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章