業內目前來說事實上的一個標準，就是分佈式搜索引擎一般大家都用elasticsearch
(1) es的分佈式架構原理能說一下麼（es是如何實現分佈式的啊）
面試官心裏分析
在搜索這塊，lucene是最流行的搜索庫。幾年前業內一般都問，你瞭解lucene嗎？
你知道倒排索引的原理嗎？現在早已經out了，因爲現在很多項目都是直接用基於lucene的分佈式搜索引擎--elasticsearch，簡稱es.
而現在分佈式搜索基本已經成爲大部分互聯網行業的java系統的標配，其中尤爲流行的就是es，前幾年es沒火的時候，大家一般用solr，但是這兩年基本大部分企業和項目都開始轉向es了。
所以互聯網面試，肯定會跟你聊聊分佈式搜索引擎，也就一定會聊聊es，如果你確實不知道，那你真的就out了。
如果面試官問你第一個問題，確實一般都會問你es的分佈式架構設計能介紹一下麼？就看看你對分佈式搜索引擎架構的一個基本理解。
面試的剖析
elasticsearch設計的理念就是分佈式搜索引擎，底層其實還是基於lucene的。
核心思想就是在多臺機器上啓動多個es進程實例，組成了一個es集羣。
es中存儲數據的基本單位是索引，比如說你現在要在es中存儲一些訂單數據，你就應該在es中創建一個索引，order_idx,所有的訂單數據就都寫到這個索引裏面去，一個索引差不多就是相當於是mysql裏的一張表。Index->type->mapping->document->field。
Index：mysql裏的一張表
Type：沒法跟mysql裏去對比，一個index裏可以有多個type，每個type的字段都是差不多的，但是有一些略微的差別。
好比說，有一個index，是訂單index，裏面專門是放訂單數據的。就好比說你在mysql中建表，有些訂單是實物商品的訂單，就好比說一件衣服，一雙鞋子，有些訂單是虛擬商品的訂單，就好比說遊戲點卡，話費充值。就兩種訂單大部分字段是一樣的，但是少部分字段可能有略微的一些差別。
所以就會在訂單index裏，建兩個type，一個是實物商品訂單type，一個是虛擬商品訂單type，這兩個type大部分字段是一樣的，少部分字段是不一樣的。
很多情況下，一個index裏可能就一個type，但是確實如果說是一個index裏有多個type的情況，你可以認爲index是一個類別的表，具體的每個type代表了具體的一個mysql中的表
每個type有一個mapping，如果你認爲一個type是一個具體的一個表，index代表了多個type的同屬於的一個類型，mapping就是這個type的表結構定義，你在mysql中創建一個表，肯定是要定義表結構的，裏面有哪些字段，每個字段是什麼類型。。。
Mapping就代表了這個type的表結構的定義，定義了這個type中每個字段名稱，字段是什麼類型的，然後還有這個字段的各種配置
實際上你往index裏的一個type裏面寫的一條數據，叫做一個document，一條document就代表了mysql中某個表裏的一行給，每個document有多個field，每個field就代表了這個document中的一個字段的值
接着你搞一個索引，這個索引可以拆分成多個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作爲一個分佈式搜索引擎最基本的一個架構設計。