1、Elasticsearch是如何實現master選舉的？

1、對所有可以成為master的節點根據nodeId排序，每次選舉每個節點都把自己所知道節點排一次序，然后選出第一個（第0位）節點，暫且認為它是master節點。 2、如果對某個節點的投票數達到一定的值（可以成為master節點數n/2+1）并且該節點自己也選舉自己，那這個節點就是master。否則重新選舉。 3、對于brain split問題，需要把候選master節點最小值設置為可以成為master節點數n/2+1（quorum ）

2、詳細描述一下 Elasticsearch 索引文檔的過程。

1、當分片所在的節點接收到來自協調節點的請求后，會將請求寫入到 MemoryBuffer，然后定時（默認是每隔 1 秒）寫入到 Filesystem Cache，這個從 MomeryBuffer 到 Filesystem Cache 的過程就叫做 refresh； 2、當然在某些情況下，存在 Momery Buffer 和 Filesystem Cache 的數據可能會丟失，ES 是通過 translog 的機制來保證數據的可靠性的。其實現機制是接收到請求后，同時也會寫入到 translog 中，當 Filesystem cache 中的數據寫入到磁盤中時，才會清除掉，這個過程叫做 flush； 3、在 flush 過程中，內存中的緩沖將被清除，內容被寫入一個新段，段的 fsync將創建一個新的提交點，并將內容刷新到磁盤，舊的 translog 將被刪除并開始一個新的 translog。 4、flush 觸發的時機是定時觸發（默認 30 分鐘）或者 translog 變得太大（默認為 512M）時；

3、詳細描述一下 Elasticsearch 更新和刪除文檔的過程。

1、刪除和更新也都是寫操作，但是 Elasticsearch 中的文檔是不可變的，因此不能被刪除或者改動以展示其變更。 2、磁盤上的每個段都有一個相應的.del 文件。當刪除請求發送后，文檔并沒有真的被刪除，而是在.del 文件中被標記為刪除。該文檔依然能匹配查詢，但是會在結果中被過濾掉。當段合并時，在.del 文件中被標記為刪除的文檔將不會被寫入新段。 3、在新的文檔被創建時，Elasticsearch 會為該文檔指定一個版本號，當執行更新時，舊版本的文檔在.del 文件中被標記為刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結果中被過濾掉。

4、詳細描述一下 Elasticsearch 搜索的過程？

1、搜索被執行成一個兩階段過程，我們稱之為 Query Then Fetch； 2、在初始查詢階段時，查詢會廣播到索引中每一個分片拷貝（主分片或者副本分片）。每個分片在本地執行搜索并構建一個匹配文檔的大小為 from + size 的優先隊列。 備注：在搜索的時候是會查詢 Filesystem Cache 的，但是有部分數據還在 MemoryBuffer，所以搜索是近實時的。 3、每個分片返回各自優先隊列中 所有文檔的 ID 和排序值 給協調節點，它合并這些值到自己的優先隊列中來產生一個全局排序后的結果列表。 4、接下來就是 取回階段，協調節點辨別出哪些文檔需要被取回并向相關的分片提交多個 GET 請求。每個分片加載并 豐富 文檔，如果有需要的話，接著返回文檔給協調節點。一旦所有的文檔都被取回了，協調節點返回結果給客戶端。 5、補充：Query Then Fetch 的搜索類型在文檔相關性打分的時候參考的是本分片的數據，這樣在文檔數量較少的時候可能不夠準確，DFS Query Then Fetch 增加了一個預查詢的處理，詢問 Term 和 Document frequency，這個評分更準確，但是性能會變差。

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

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

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

1、可以通過版本號使用樂觀并發控制，以確保新版本不會被舊版本覆蓋，由應用層來處理具體的沖突； 2、另外對于寫操作，一致性級別支持 quorum/one/all，默認為 quorum，即只有當大多數分片可用時才允許寫操作。但即使大多數可用，也可能存在因為網絡等原因導致寫入副本失敗，這樣該副本被認為故障，分片將會在一個不同的節點上重建。 3、對于讀操作，可以設置 replication 為 sync(默認)，這使得操作在主分片和副本分片都完成后才會返回；如果設置 replication 為 async 時，也可以通過設置搜索請求參數_preference 為 primary 來查詢主分片，確保文檔是最新版本。

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

群集：一個或多個節點（服務器）的集合，它們共同保存您的整個數據，并提供跨所有節點的聯合索引和搜索功能。群集由唯一名稱標識，默認情況下為“elasticsearch”。此名稱很重要，因為如果節點設置為按名稱加入群集，則該節點只能是群集的一部分?！　」濣c：屬于集群一部分的單個服務器。它存儲數據并參與群集索引和搜索功能?！　∷饕?#xff1a;就像關系數據庫中的“數據庫”。它有一個定義多種類型的映射。索引是邏輯名稱空間，映射到一個或多個主分片，并且可以有零個或多個副本分片。 eg: MySQL =>數據庫 　　 ElasticSearch =>索引 　　文檔：類似于關系數據庫中的一行。不同之處在于索引中的每個文檔可以具有不同的結構（字段），但是對于通用字段應該具有相同的數據類型。 MySQL => Databases => 　 Tables => Columns / Rows ElasticSearch => Indices => Types =>具有屬性的文檔類型：是索引的邏輯類別/分區，其語義完全取決于用戶。

8、Elasticsearch的倒排索引是什么？

1、倒排索引是搜索引擎的核心。搜索引擎的主要目標是在查找發生搜索條件的文檔時提供快速搜索。倒排索引是一種像數據結構一樣的散列圖，可將用戶從單詞導向文檔或網頁。它是搜索引擎的核心。其主要目標是快速搜索從數百萬文件中查找數據。 2、傳統的我們的檢索是通過文章，逐個遍歷找到對應關鍵詞的位置。而倒排索引，是通過分詞策略，形成了詞和文章的映射關系表，這種詞典+映射表即為倒排索引。有了倒排索引，就能實現o（1）時間復雜度的效率檢索文章了，極大的提高了檢索效率。學術的解答方式： 倒排索引，相反于一篇文章包含了哪些詞，它從詞出發，記載了這個詞在哪些文檔中出現過，由兩部分組成——詞典和倒排表。 加分項：倒排索引的底層實現是基于：FST（Finite State Transducer）數據結構。 lucene從4+版本后開始大量使用的數據結構是FST。FST有兩個優點： 1）空間占用小。通過對詞典中單詞前綴和后綴的重復利用，壓縮了存儲空間； 2）查詢速度快。O(len(str))的查詢時間復雜度。

9、ElasticSearch中的分析器是什么？

1、在ElasticSearch中索引數據時，數據由為索引定義的Analyzer在內部進行轉換。分析器由一個Tokenizer和零個或多個TokenFilter組成。編譯器可以在一個或多個CharFilter之前。分析模塊允許您在邏輯名稱下注冊分析器，然后可以在映射定義或某些API中引用它們。 2、Elasticsearch附帶了許多可以隨時使用的預建分析器?；蛘?#xff0c;您可以組合內置的字符過濾器，編譯器和過濾器器來創建自定義分析器。

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

1、Enabled屬性適用于各類ElasticSearch特定/創建領域，如index和size。用戶提供的字段沒有“已啟用”屬性。存儲意味著數據由Lucene存儲，如果詢問，將返回這些數據。 2、存儲字段不一定是可搜索的。默認情況下，字段不存儲，但源文件是完整的。因為您希望使用默認值(這是有意義的)，所以不要設置store屬性 該指數屬性用于搜索。 3、索引屬性只能用于搜索。只有索引域可以進行搜索。差異的原因是在分析期間對索引字段進行了轉換，因此如果需要的話，您不能檢索原始數據。

11、Elasticsearch了解多少，說說你們公司es的集群架構，索引數據大小，分片有多少，以及一些調優手段 。

比如：ES集群架構13個節點，索引根據通道不同共20+索引，根據日期，每日遞增20+，索引：10分片，每日遞增1億+數據，每個通道每天索引大小控制：150GB之內。 僅索引層面調優手段：1.1、設計階段調優 1）根據業務增量需求，采取基于日期模板創建索引，通過roll over API滾動索引； 2）使用別名進行索引管理； 3）每天凌晨定時對索引做force_merge操作，以釋放空間； 4）采取冷熱分離機制，熱數據存儲到SSD，提高檢索效率；冷數據定期進行shrink操作，以縮減存儲； 5）采取curator進行索引的生命周期管理； 6）僅針對需要分詞的字段，合理的設置分詞器； 7）Mapping階段充分結合各個字段的屬性，是否需要檢索、是否需要存儲等?！?.2、寫入調優 1）寫入前副本數設置為0； 2）寫入前關閉refresh_interval設置為-1，禁用刷新機制； 3）寫入過程中：采取bulk批量寫入； 4）寫入后恢復副本數和刷新間隔； 5）盡量使用自動生成的id。1.3、查詢調優 1）禁用wildcard； 2）禁用批量terms（成百上千的場景）； 3）充分利用倒排索引機制，能keyword類型盡量keyword； 4）數據量大時候，可以先基于時間敲定索引再檢索； 5）設置合理的路由機制。1.4、其他調優部署調優，業務調優等。

12、Elasticsearch 索引數據多了怎么辦，如何調優，部署？

1 動態索引層面 基于模板+時間+rollover api滾動創建索引，舉例：設計階段定義：blog索引的模板格式為：blog_index_時間戳的形式，每天遞增數據。這樣做的好處：不至于數據量激增導致單個索引數據量非常大，接近于上線2的32次冪-1，索引存儲達到了TB+甚至更大。一旦單個索引很大，存儲等各種風險也隨之而來，所以要提前考慮+及早避免。2 存儲層面 冷熱數據分離存儲，熱數據（比如最近3天或者一周的數據），其余為冷數據。對于冷數據不會再寫入新數據，可以考慮定期force_merge加shrink壓縮操作，節省存儲空間和檢索效率。3 部署層面 一旦之前沒有規劃，這里就屬于應急策略。結合ES自身的支持動態擴展的特點，動態新增機器的方式可以緩解集群壓力，注意：如果之前主節點等規劃合理，不需要重啟集群也能完成動態新增的。

13、在使用 Elasticsearch 時要注意什么？

由于ES使用的Java寫的，所有注意的是GC方面的問題

1、倒排詞典的索引需要常駐內存，無法 GC，需要監控 data node 上 segmentmemory 增長趨勢。 2、各類緩存，field cache, filter cache, indexing cache, bulk queue 等等，要設置合理的大小，并且要應該根據最壞的情況來看 heap 是否夠用，也就是各類緩存全部占滿的時候，還有 heap 空間可以分配給其他任務嗎？避免采用 clear cache等“自欺欺人”的方式來釋放內存。 3、避免返回大量結果集的搜索與聚合。確實需要大量拉取數據的場景，可以采用scan & scroll api 來實現。 4、cluster stats 駐留內存并無法水平擴展，超大規模集群可以考慮分拆成多個集群通過 tribe node 連接 5、想知道 heap 夠不夠，必須結合實際應用場景，并對集群的 heap 使用情況做持續的監控。

14、Elasticsearch 支持哪些類型的查詢？

查詢主要分為兩種類型：精確匹配、全文檢索匹配。 精確匹配，例如 term、exists、term set、 range、prefix、 ids、 wildcard、regexp、 fuzzy等。 全文檢索，例如match、match_phrase、multi_match、match_phrase_prefix、query_string 等

15、你能否列出與 Elasticsearch 有關的主要可用字段數據類型？

1、字符串數據類型，包括支持全文檢索的 text 類型 和 精準匹配的 keyword 類型。 2、數值數據類型，例如字節，短整數，長整數，浮點數，雙精度數，half_float，scaled_float。 3、日期類型，日期納秒Date nanoseconds，布爾值，二進制（Base64編碼的字符串）等。 4、范圍（整數范圍 integer_range，長范圍 long_range，雙精度范圍 double_range，浮動范圍 float_range，日期范圍 date_range）。 5、包含對象的復雜數據類型，nested 、Object。 6、GEO 地理位置相關類型。 7、特定類型如：數組（數組中的值應具有相同的數據類型）

16、如何監控 Elasticsearch 集群狀態？

Marvel 讓你可以很簡單的通過 Kibana 監控 Elasticsearch。你可以實時查看你的集群健康狀態和性能，也可以分析過去的集群、索引和節點指標。

17、有了解過Elasticsearch的性化搜索方案嗎？

基于word2vec和Elasticsearch實現個性化搜索 （1）基于word2vec、Elasticsearch和自定義的腳本插件，我們就實現了一個個性化的搜索服務，相對于原有的實現，新版的點擊率和轉化率都有大幅的提升； （2）基于word2vec的商品向量還有一個可用之處，就是可以用來實現相似商品的推薦； （3）使用word2vec來實現個性化搜索或個性化推薦是有一定局限性的，因為它只能處理用戶點擊歷史這樣的時序數據，而無法全面的去考慮用戶偏好，這個還是有很大的改進和提升的空間；

18、是否了解字典樹？

數據結構優缺點

Array/List	使用二分法查找，不平衡
HashMap/TreeMap	性能高，內存消耗大，幾乎是原始數據的三倍
Skip List	跳躍表，可快速查找詞語，在lucene,redis,HBase中有實現
Trie	適合英文詞典，如果系統中存在大量字符串且這些字符串基本沒有公共前綴
Double Array Trie	適合做中文詞典，內存占用小，很多分詞工具軍采用此種算法
Ternary Search Tree	一種有狀態的轉移機，Lucene 4有開源實現，并大量使用

Trie 的核心思想是空間換時間，利用字符串的公共前綴來降低查詢時間的開銷以

達到提高效率的目的。它有 3 個基本性質：

1、根節點不包含字符，除根節點外每一個節點都只包含一個字符。

2、從根節點到某一節點，路徑上經過的字符連接起來，為該節點對應的字符串。

3、每個節點的所有子節點包含的字符都不相同。

1、可以看到，trie 樹每一層的節點數是 26^i 級別的。所以為了節省空間，我們還可以用動態鏈表，或者用數組來模擬動態。而空間的花費，不會超過單詞數×單詞長度。2、實現：對每個結點開一個字母集大小的數組，每個結點掛一個鏈表，使用左兒子右兄弟表示法記錄這棵樹；3、對于中文的字典樹，每個節點的子節點用一個哈希表存儲，這樣就不用浪費太大的空間，而且查詢速度上可以保留哈希的復雜度 O(1)。

19、ElasticSearch是否有架構？

1、ElasticSearch可以有一個架構。架構是描述文檔類型以及如何處理文檔的不同字段的一個或多個字段的描述。Elasticsearch中的架構是一種映射，它描述了JSON文檔中的字段及其數據類型，以及它們應該如何在Lucene索引中進行索引。因此，在Elasticsearch術語中，我們通常將此模式稱為“映射”。 2、Elasticsearch具有架構靈活的能力，這意味著可以在不明確提供架構的情況下索引文檔。如果未指定映射，則默認情況下，Elasticsearch會在索引期間檢測文檔中的新字段時動態生成一個映射。

20、為什么要使用Elasticsearch?

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

總結

以上是生活随笔為你收集整理的2021年春招Elasticsearch面试题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。