1.為什么要使用Elasticsearch?

? 　　因為在我們商城中的數據，將來會非常多，所以采用以往的模糊查詢，模糊查詢前置配置，會放棄索引，導致商品查詢是全表掃面，在百萬級別的數據庫中，效率非常低下，而我們使用ES做一個全文索引，我們將經常查詢的商品的某些字段，比如說商品名，描述、價格還有id這些字段我們放入我們索引庫里，可以提高查詢速度。

2.Elasticsearch是如何實現Master選舉的？

Elasticsearch的選主是ZenDiscovery模塊負責的，主要包含Ping（節點之間通過這個RPC來發現彼此）和Unicast（單播模塊包含一個主機列表以控制哪些節點需要ping通）這兩部分；

對所有可以成為master的節點（node.master: true）根據nodeId字典排序，每次選舉每個節點都把自己所知道節點排一次序，然后選出第一個（第0位）節點，暫且認為它是master節點。

如果對某個節點的投票數達到一定的值（可以成為master節點數n/2+1）并且該節點自己也選舉自己，那這個節點就是master。否則重新選舉一直到滿足上述條件。

補充：master節點的職責主要包括集群、節點和索引的管理，不負責文檔級別的管理；data節點可以關閉http功能。

3.Elasticsearch中的節點（比如共20個），其中的10個選了一個master，另外10個選了另一個master，怎么辦？

當集群master候選數量不小于3個時，可以通過設置最少投票通過數量（discovery.zen.minimum_master_nodes）超過所有候選節點一半以上來解決腦裂問題；

當候選數量為兩個時，只能修改為唯一的一個master候選，其他作為data節點，避免腦裂問題。

4.詳細描述一下Elasticsearch索引文檔的過程。

協調節點默認使用文檔ID參與計算（也支持通過routing），以便為路由提供合適的分片。

shard = hash(document_id) % (num_of_primary_shards)

當分片所在的節點接收到來自協調節點的請求后，會將請求寫入到Memory Buffer，然后定時（默認是每隔1秒）寫入到Filesystem Cache，這個從Momery Buffer到Filesystem 　　Cache的過程就叫做refresh；

當然在某些情況下，存在Momery Buffer和Filesystem Cache的數據可能會丟失，ES是通過translog的機制來保證數據的可靠性的。其實現機制是接收到請求后，同時也會寫入到translog中，當Filesystem cache中的數據寫入到磁盤中時，才會清除掉，這個過程叫做flush；

在flush過程中，內存中的緩沖將被清除，內容被寫入一個新段，段的fsync將創建一個新的提交點，并將內容刷新到磁盤，舊的translog將被刪除并開始一個新的translog。

flush觸發的時機是定時觸發（默認30分鐘）或者translog變得太大（默認為512M）時；

5.詳細描述一下Elasticsearch更新和刪除文檔的過程

刪除和更新也都是寫操作，但是Elasticsearch中的文檔是不可變的，因此不能被刪除或者改動以展示其變更；

磁盤上的每個段都有一個相應的.del文件。當刪除請求發送后，文檔并沒有真的被刪除，而是在.del文件中被標記為刪除。該文檔依然能匹配查詢，但是會在結果中被過濾掉。當段合并時，在.del文件中被標記為刪除的文檔將不會被寫入新段。

在新的文檔被創建時，Elasticsearch會為該文檔指定一個版本號，當執行更新時，舊版本的文檔在.del文件中被標記為刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結果中被過濾掉。

6.詳細描述一下Elasticsearch搜索的過程

搜索被執行成一個兩階段過程，我們稱之為 Query Then Fetch；

在初始查詢階段時，查詢會廣播到索引中每一個分片拷貝（主分片或者副本分片）。 每個分片在本地執行搜索并構建一個匹配文檔的大小為 from + size 的優先隊列。PS：在搜索的時候是會查詢Filesystem Cache的，但是有部分數據還在Memory Buffer，所以搜索是近實時的。

每個分片返回各自優先隊列中 所有文檔的 ID 和排序值 給協調節點，它合并這些值到自己的優先隊列中來產生一個全局排序后的結果列表。

接下來就是 取回階段，協調節點辨別出哪些文檔需要被取回并向相關的分片提交多個 GET 請求。每個分片加載并 豐富 文檔，如果有需要的話，接著返回文檔給協調節點。一旦所有的文檔都被取回了，協調節點返回結果給客戶端。

補充：Query Then Fetch的搜索類型在文檔相關性打分的時候參考的是本分片的數據，這樣在文檔數量較少的時候可能不夠準確，DFS Query Then Fetch增加了一個預查詢的處理，詢問Term和Document frequency，這個評分更準確，但是性能會變差。

9.Elasticsearch對于大數據量（上億量級）的聚合如何實現？

? 　　Elasticsearch 提供的首個近似聚合是cardinality 度量。它提供一個字段的基數，即該字段的distinct或者unique值的數目。它是基于HLL算法的。HLL 會先對我們的輸入作哈希運算，然后根據哈希運算的結果中的 bits 做概率估算從而得到基數。其特點是：可配置的精度，用來控制內存的使用（更精確 ＝ 更多內存）；小的數據集精度是非常高的；我們可以通過配置參數，來設置去重需要的固定內存使用量。無論數千還是數十億的唯一值，內存使用量只與你配置的精確度相關 .

10.在并發情況下，Elasticsearch如果保證讀寫一致？

可以通過版本號使用樂觀并發控制，以確保新版本不會被舊版本覆蓋，由應用層來處理具體的沖突；

另外對于寫操作，一致性級別支持quorum/one/all，默認為quorum，即只有當大多數分片可用時才允許寫操作。但即使大多數可用，也可能存在因為網絡等原因導致寫入副本失敗，這樣該副本被認為故障，分片將會在一個不同的節點上重建。

對于讀操作，可以設置replication為sync(默認)，這使得操作在主分片和副本分片都完成后才會返回；如果設置replication為async時，也可以通過設置搜索請求參數_preference為primary來查詢主分片，確保文檔是最新版本。

14.ElasticSearch中的集群、節點、索引、文檔、類型是什么？

群集是一個或多個節點（服務器）的集合，它們共同保存您的整個數據，并提供跨所有節點的聯合索引和搜索功能。群集由唯一名稱標識，默認情況下為“elasticsearch”。此名稱很重要，因為如果節點設置為按名稱加入群集，則該節點只能是群集的一部分。

節點是屬于集群一部分的單個服務器。它存儲數據并參與群集索引和搜索功能。

索引就像關系數據庫中的“數據庫”。它有一個定義多種類型的映射。索引是邏輯名稱空間，映射到一個或多個主分片，并且可以有零個或多個副本分片。 MySQL =>數據庫 　　 ElasticSearch =>索引

文檔類似于關系數據庫中的一行。不同之處在于索引中的每個文檔可以具有不同的結構（字段），但是對于通用字段應該具有相同的數據類型。 MySQL => Databases => 　 Tables => Columns / Rows ElasticSearch => Indices => Types =>具有屬性的文檔

類型是索引的邏輯類別/分區，其語義完全取決于用戶。

15.ElasticSearch中的分片是什么?

　　在大多數環境中，每個節點都在單獨的盒子或虛擬機上運行。

索引 - 在Elasticsearch中，索引是文檔的集合。

分片 -因為Elasticsearch是一個分布式搜索引擎，所以索引通常被分割成分布在多個節點上的被稱為分片的元素。

問題四：

ElasticSearch中的集群、節點、索引、文檔、類型是什么？

群集是一個或多個節點（服務器）的集合，它們共同保存您的整個數據，并提供跨所有節點的聯合索引和搜索功能。群集由唯一名稱標識，默認情況下為“elasticsearch”。此名稱很重要，因為如果節點設置為按名稱加入群集，則該節點只能是群集的一部分。

節點是屬于集群一部分的單個服務器。它存儲數據并參與群集索引和搜索功能。

索引就像關系數據庫中的“數據庫”。它有一個定義多種類型的映射。索引是邏輯名稱空間，映射到一個或多個主分片，并且可以有零個或多個副本分片。 MySQL =>數據庫 ElasticSearch =>索引

文檔類似于關系數據庫中的一行。不同之處在于索引中的每個文檔可以具有不同的結構（字段），但是對于通用字段應該具有相同的數據類型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有屬性的文檔

類型是索引的邏輯類別/分區，其語義完全取決于用戶。

問題五：

ElasticSearch是否有架構？

ElasticSearch可以有一個架構。架構是描述文檔類型以及如何處理文檔的不同字段的一個或多個字段的描述。Elasticsearch中的架構是一種映射，它描述了JSON文檔中的字段及其數據類型，以及它們應該如何在Lucene索引中進行索引。因此，在Elasticsearch術語中，我們通常將此模式稱為“映射”。

Elasticsearch具有架構靈活的能力，這意味著可以在不明確提供架構的情況下索引文檔。如果未指定映射，則默認情況下，Elasticsearch會在索引期間檢測文檔中的新字段時動態生成一個映射。

問題六：

ElasticSearch中的分片是什么？

在大多數環境中，每個節點都在單獨的盒子或虛擬機上運行。

索引 - 在Elasticsearch中，索引是文檔的集合。

分片 -因為Elasticsearch是一個分布式搜索引擎，所以索引通常被分割成分布在多個節點上的被稱為分片的元素。

問題七：

ElasticSearch中的副本是什么？

一個索引被分解成碎片以便于分發和擴展。副本是分片的副本。一個節點是一個屬于一個集群的ElasticSearch的運行實例。一個集群由一個或多個共享相同集群名稱的節點組成。

問題八：

ElasticSearch中的分析器是什么？

在ElasticSearch中索引數據時，數據由為索引定義的Analyzer在內部進行轉換。 分析器由一個Tokenizer和零個或多個TokenFilter組成。編譯器可以在一個或多個CharFilter之前。分析模塊允許您在邏輯名稱下注冊分析器，然后可以在映射定義或某些API中引用它們。

Elasticsearch附帶了許多可以隨時使用的預建分析器?；蛘?，您可以組合內置的字符過濾器，編譯器和過濾器器來創建自定義分析器。

問題九：

什么是ElasticSearch中的編譯器？

編譯器用于將字符串分解為術語或標記流。一個簡單的編譯器可能會將字符串拆分為任何遇到空格或標點的地方。Elasticsearch有許多內置標記器，可用于構建自定義分析器。

問題十一：

啟用屬性，索引和存儲的用途是什么？

enabled屬性適用于各類ElasticSearch特定/創建領域，如index和size。用戶提供的字段沒有“已啟用”屬性。 存儲意味著數據由Lucene存儲，如果詢問，將返回這些數據。

存儲字段不一定是可搜索的。默認情況下，字段不存儲，但源文件是完整的。因為您希望使用默認值(這是有意義的)，所以不要設置store屬性 該指數屬性用于搜索。

索引屬性只能用于搜索。只有索引域可以進行搜索。差異的原因是在分析期間對索引字段進行了轉換，因此如果需要的話，您不能檢索原始數據。

（網絡搜集-博客園）

第二部分面試題

es 寫入數據的工作原理是什么??？es 查詢數據的工作原理是什么啊？底層的 lucene 介紹一下唄？倒排索引了解嗎？

面試官心理分析

問這個，其實面試官就是要看看你了解不了解 es 的一些基本原理，因為用 es 無非就是寫入數據，搜索數據。你要是不明白你發起一個寫入和搜索請求的時候，es 在干什么，那你真的是......對 es 基本就是個黑盒，你還能干啥？你唯一能干的就是用 es 的 api 讀寫數據了。要是出點什么問題，你啥都不知道，那還能指望你什么呢？

es 寫數據過程

客戶端選擇一個 node 發送請求過去，這個 node 就是?coordinating node（協調節點）。

coordinating node?對 document 進行路由，將請求轉發給對應的 node（有 primary shard）。[路由的算法是？]

實際的 node 上的?primary shard?處理請求，然后將數據同步到?replica node。

coordinating node?如果發現?primary node?和所有?replica node?都搞定之后，就返回響應結果給客戶端。

es 讀數據過程

可以通過?doc id?來查詢，會根據?doc id?進行 hash，判斷出來當時把?doc id?分配到了哪個 shard 上面去，從那個 shard 去查詢。

客戶端發送請求到任意一個 node，成為?coordinate node。

coordinate node?對?doc id?進行哈希路由，將請求轉發到對應的 node，此時會使用?round-robin隨機輪詢算法，在?primary shard?以及其所有 replica 中隨機選擇一個，讓讀請求負載均衡。

接收請求的 node 返回 document 給?coordinate node。

coordinate node?返回 document 給客戶端。

寫請求是寫入 primary shard，然后同步給所有的 replica shard；讀請求可以從 primary shard 或 replica shard 讀取，采用的是隨機輪詢算法。

es 搜索數據過程[是指search?search和普通docid get的背后邏輯不一樣？]

es 最強大的是做全文檢索，就是比如你有三條數據：

java真好玩兒啊

java好難學啊

j2ee特別牛

你根據?java?關鍵詞來搜索，將包含?java的?document?給搜索出來。es 就會給你返回：java真好玩兒啊，java好難學啊。

客戶端發送請求到一個?coordinate node。

協調節點將搜索請求轉發到所有的 shard 對應的?primary shard?或?replica shard，都可以。

query phase：每個 shard 將自己的搜索結果（其實就是一些?doc id）返回給協調節點，由協調節點進行數據的合并、排序、分頁等操作，產出最終結果。

fetch phase：接著由協調節點根據?doc id?去各個節點上拉取實際的?document?數據，最終返回給客戶端。

寫數據底層原理

1）document先寫入導內存buffer中，同時寫translog日志

2)）https://www.elastic.co/guide/cn/elasticsearch/guide/current/near-real-time.html

refresh操作所以近實時搜索：寫入和打開一個新段(一個追加的倒排索引)的輕量的過程叫做?refresh?。每隔一秒鐘把buffer中的數據創建一個新的segment，這里新段會被先寫入到文件系統緩存--這一步代價會比較低，稍后再被刷新到磁盤--這一步代價比較高。不過只要文件已經在緩存中， 就可以像其它文件一樣被打開和讀取了，內存buffer被清空。此時，新segment 中的文件就可以被搜索了，這就意味著document從被寫入到可以被搜索需要一秒種，如果要更改這個屬性，可以執行以下操作

PUT /my_index

{

"settings": {

"refresh_interval": "30s"

}

}

3）https://www.elastic.co/guide/cn/elasticsearch/guide/current/translog.html

flush操作導致持久化變更：執行一個提交并且截斷 translog 的行為在 Elasticsearch 被稱作一次?flush。刷新（refresh）完成后, 緩存被清空但是事務日志不會。translog日志也會越來越多，當translog日志大小大于一個閥值時候或30分鐘，會出發flush操作。

所有在內存緩沖區的文檔都被寫入一個新的段。

緩沖區被清空。

一個提交點被寫入硬盤。（表明有哪些segment commit了）

文件系統緩存通過?fsync?到磁盤。

老的 translog 被刪除。

分片每30分鐘被自動刷新（flush），或者在 translog 太大的時候也會刷新。也可以用_flush命令手動執行。

translog每隔5秒會被寫入磁盤（所以如果這5s，數據在cache而且log沒持久化會丟失）。在一次增刪改操作之后translog只有在replica和primary shard都成功才會成功，如果要提高操作速度，可以設置成異步的

PUT /my_index

{

"settings": {

"index.translog.durability": "async" ,

"index.translog.sync_interval":"5s"

}

}

所以總結是有三個批次操作，一秒做一次refresh保證近實時搜索，5秒做一次translog持久化保證數據未持久化前留底，30分鐘做一次數據持久化。

2.基于translog和commit point的數據恢復

在磁盤上會有一個上次持久化的commit point，translog上有一個commit point，根據這兩個commit point，會把translog中的變更記錄進行回放，重新執行之前的操作

3.不變形下的刪除和更新原理

https://www.elastic.co/guide/cn/elasticsearch/guide/current/dynamic-indices.html#deletes-and-updates

一個文檔被 “刪除” 時，它實際上只是在?.del?文件中被?標記?刪除。一個被標記刪除的文檔仍然可以被查詢匹配到， 但它會在最終結果被返回前從結果集中移除。

文檔更新也是類似的操作方式：當一個文檔被更新時，舊版本文檔被標記刪除，文檔的新版本被索引到一個新的段中。 可能兩個版本的文檔都會被一個查詢匹配到，但被刪除的那個舊版本文檔在結果集返回前就已經被移除。

段合并的時候會將那些舊的已刪除文檔 從文件系統中清除。 被刪除的文檔（或被更新文檔的舊版本）不會被拷貝到新的大段中。

4.merge操作，段合并

https://www.elastic.co/guide/cn/elasticsearch/guide/current/merge-process.html

由于每秒會把buffer刷到segment中，所以segment會很多，為了防止這種情況出現，es內部會不斷把一些相似大小的segment合并，并且物理刪除del的segment。

當然也可以手動執行

POST /my_index/_optimize?max_num_segments=1，盡量不要手動執行，讓它自動默認執行就可以了

5.當你正在建立一個大的新索引時（相當于直接全部寫入buffer，先不refresh，寫完再refresh），可以先關閉自動刷新，待開始使用該索引時，再把它們調回來：

PUT /my_logs/_settings

{ "refresh_interval": -1 }

PUT /my_logs/_settings

{ "refresh_interval": "1s" }

底層 lucene

簡單來說，lucene 就是一個 jar 包，里面包含了封裝好的各種建立倒排索引的算法代碼。我們用 Java 開發的時候，引入 lucene jar，然后基于 lucene 的 api 去開發就可以了。

通過 lucene，我們可以將已有的數據建立索引，lucene 會在本地磁盤上面，給我們組織索引的數據結構。

倒排索引

在搜索引擎中，每個文檔都有一個對應的文檔 ID，文檔內容被表示為一系列關鍵詞的集合。例如，文檔 1 經過分詞，提取了 20 個關鍵詞，每個關鍵詞都會記錄它在文檔中出現的次數和出現位置。

那么，倒排索引就是關鍵詞到文檔 ID 的映射，每個關鍵詞都對應著一系列的文件，這些文件中都出現了關鍵詞。

舉個栗子。

有以下文檔：

對文檔進行分詞之后，得到以下倒排索引。

另外，實用的倒排索引還可以記錄更多的信息，比如文檔頻率信息，表示在文檔集合中有多少個文檔包含某個單詞。

那么，有了倒排索引，搜索引擎可以很方便地響應用戶的查詢。比如用戶輸入查詢?Facebook，搜索系統查找倒排索引，從中讀出包含這個單詞的文檔，這些文檔就是提供給用戶的搜索結果。

要注意倒排索引的兩個重要細節：

倒排索引中的所有詞項對應一個或多個文檔

倒排索引中的詞項根據字典順序升序排列

上面只是一個簡單的例子，并沒有嚴格按照字典順序升序排列。