突破Java面試(14)-分佈式搜索引擎的架構

如下用ES表Elastic Search

0 Github

1 面試題

說說ES的分佈式架構原理

2 考點分析

在搜索這塊，曾經lucene 是最流行的搜索庫. 幾年前業內通常都問，你瞭解 lucene 嗎？你知道倒排索引的原理嗎？ 但如今不問了,由於如今項目基本都是採用基於 lucene 的分佈式搜索引擎—— ElasticSearch.

如今分佈式搜索基本已經成爲互聯網系統的標配，其中尤其流行的就是 ES，前幾年通常用 solr。可是最近基本大部分企業和項目都開始轉向 ES.

因此互聯網面試，確定會跟你聊聊分佈式搜索引擎，就必定會聊到ES!

若是面試官問你第一個問題，確實通常都會問你 es 的分佈式架構設計能介紹一下麼？就看看你對分佈式搜索引擎架構的一個基本理解。

3 詳解

ES的設計理念就是分佈式搜索引擎，底層其實仍是基於 lucene 的. 核心思想就是在多臺機器上啓動多ES進程實例，組成ES集羣.

3.1 基本單位

ES 中存儲數據的基本單位是索引. 好比說你如今要在 ES 中存儲一些訂單數據，應該在 ES 中建立一個索引 order_idx,全部的訂單數據就會寫到該索引中. 一個索引概念上差很少就至關於MySQL 中的一張表.

index -> type -> mapping -> document -> field。
複製代碼

3.2 實例

爲便於理解,我在這裏作個類比.切記,僅僅是類比!毫不等同!

index 至關於 MySQL 裏的一張表; 而 type 無法跟 MySQL 裏去類比; 一個 index 裏能夠有多個 type，每一個 type 的字段都是差很少的，也有略微差異.

假設有一個訂單 index，專門存放訂單數據. 就比如說你在 MySQL 中建表

• 有些訂單是實物商品的訂單，好比一件衣服、一雙鞋子
• 有些訂單是虛擬商品的訂單，好比遊戲點卡，話費充值

這兩種訂單大部分字段是同樣的，可是少部分字段仍是有略微差異.

相似地,ES就會在訂單 index,建兩個 type

• 一個是實物商品訂單 type
• 一個是虛擬商品訂單 type

這兩個 type 大部分字段是同樣的，少部分字段是不同的。

不少狀況下，一個 index 裏可能就一個 type，可是確實若是說是一個 index 裏有多個 type 的狀況

mapping types 這個概念在 ElasticSearch 7.X 已被徹底移除，詳細說明參考官方文檔

你能夠認爲 index 是一個類別的表，具體的每一個 type 表明了 MySQL 中的一個表. 每一個 type 有一個 mapping,若是假設一個 type 是具體的一個表,index 就表明多個 type 同屬於的一個類型,而 mapping 就是這個 type 的表結構定義. 你在 MySQL 中建立一個表，確定是要定義表結構的，裏面有哪些字段，每一個字段是什麼類型. 實際上你往 index 裏的一個 type 裏面寫的一條數據，叫作一條 document; 一條 document 就相似 MySQL 中某個表裏的一行; 每一個 document 有多個 field; 每一個 field 就表明該 document 中的一個字段的值.

3.3 結構原理

你創建一個索引,該索引又可拆分紅多個 shard,每一個 shard 存儲部分數據. 拆分紅多個 shard 是有好處的

• 支持橫向擴展 好比你數據量 3T，3 個 shard,每一個 shard 就 1T 的數據,若如今數據量增到 4T,怎麼擴展? so easy!新建一個有 4 個 shard 的索引，將數據導入
• 提升性能 數據分佈在多個 shard,即多臺服務器上,全部的操做,都會在多臺機器上並行分佈式執行,提升了系統的吞吐量和性能.

接着就是這個 shard 的數據實際是有多個備份,即每一個 shard 都有一個 primary shard負責寫入數據,還有幾個 replica shard. primary shard 寫入數據後,會將數據同步到其餘幾個 replica shard 中.

經過 replica 方案,每一個 shard 數據都有多個備份. 即便某個節點宕機,其餘節點上還有數據,知足高可用性.

3.4 主從特性

ES 集羣的多個節點,會自動選舉一個節點爲 master 節點; master 節點負責一些管理工做,好比維護索引元數據、切換primary shard 和replica shard 身份等; 若 master 節點宕機,則會從新選舉一個節點爲 master.

若非 master 節點宕機了,則 master 節點會使宕機節點上的primary shard的身份轉移到其餘可用節點上的 replica shard. 接着你要是修復了那個宕機節點,重啓後,master 節點會控制將缺失的replica shard 分配回去,而且同步後續修改的數據之類的,讓集羣恢復正常.

更簡單點,若某非 master 節點宕機了,那麼該節點上的 primary shard不也就沒了嘛. 那好,master 會讓primary shard 對應的 replica shard（在其餘節點上）切換爲primary shard.待宕機的節點修復了,修復後的節點也再也不是 primary shard了,而是 replica shard.

以上就是 ElasticSearch 做爲分佈式搜索引擎最基本的架構設計.

參考

《Java工程師面試突擊第1季-中華石杉老師》

更多幹貨資源請關注JavaEdge公衆號