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是一個分佈式搜索引擎，所以索引通常被分割成分佈在多個節點上的被稱爲分片的元素。
16.Elasticsearch中的倒排索引是什麼？
解答：通俗解釋一下就可以。傳統的我們的檢索是通過文章，逐個遍歷找到對應關鍵詞的位置。而倒排索引，是通過分詞策略，形成了詞和文章的映射關係表，這種詞典+映射表即爲倒排索引。有了倒排索引，就能實現 o（1）時間複雜度的效率檢索文章了，極大的提高了檢索效率。
學術的解答方式：倒排索引，相反於一篇文章包含了哪些詞，它從詞出發，記載了這個詞在哪些文檔中出現過，由兩部分組成——詞典和倒排表。
加分項：倒排索引的底層實現是基於：FST（Finite State Transducer）數據結構。lucene 從 4+版本後開始大量使用的數據結構是 FST。FST 有兩個優點：
（1）空間佔用小。通過對詞典中單詞前綴和後綴的重複利用，壓縮了存儲空間；
（2）查詢速度快。O(len(str))的查詢時間複雜度。
問題五：
ElasticSearch是否有架構？
ElasticSearch可以有一個架構。架構是描述文檔類型以及如何處理文檔的不同字段的一個或多個字段的描述。Elasticsearch中的架構是一種映射，它描述了JSON文檔中的字段及其數據類型，以及它們應該如何在Lucene索引中進行索引。因此，在Elasticsearch術語中，我們通常將此模式稱爲“映射”。
Elasticsearch具有架構靈活的能力，這意味着可以在不明確提供架構的情況下索引文檔。如果未指定映射，則默認情況下，Elasticsearch會在索引期間檢測文檔中的新字段時動態生成一個映射。
問題七：
ElasticSearch中的副本是什麼？
一個索引被分解成碎片以便於分發和擴展。副本是分片的副本。一個節點是一個屬於一個集羣的ElasticSearch的運行實例。一個集羣由一個或多個共享相同集羣名稱的節點組成。
問題八：
ElasticSearch中的分析器是什麼？
在ElasticSearch中索引數據時，數據由爲索引定義的Analyzer在內部進行轉換。 分析器由一個Tokenizer和零個或多個TokenFilter組成。編譯器可以在一個或多個CharFilter之前。分析模塊允許您在邏輯名稱下注冊分析器，然後可以在映射定義或某些API中引用它們。
Elasticsearch附帶了許多可以隨時使用的預建分析器。或者，您可以組合內置的字符過濾器，編譯器和過濾器器來創建自定義分析器。
問題九：
什麼是ElasticSearch中的編譯器？
編譯器用於將字符串分解爲術語或標記流。一個簡單的編譯器可能會將字符串拆分爲任何遇到空格或標點的地方。Elasticsearch有許多內置標記器，可用於構建自定義分析器。
問題十一：
啓用屬性，索引和存儲的用途是什麼？
enabled屬性適用於各類ElasticSearch特定/創建領域，如index和size。用戶提供的字段沒有“已啓用”屬性。 存儲意味着數據由Lucene存儲，如果詢問，將返回這些數據。
存儲字段不一定是可搜索的。默認情況下，字段不存儲，但源文件是完整的。因爲您希望使用默認值(這是有意義的)，所以不要設置store屬性 該指數屬性用於搜索。
索引屬性只能用於搜索。只有索引域可以進行搜索。差異的原因是在分析期間對索引字段進行了轉換，因此如果需要的話，您不能檢索原始數據。
elasticsearch 索引數據多了怎麼辦，如何調優，部署
面試官：想了解大數據量的運維能力。
解答：索引數據的規劃，應在前期做好規劃，正所謂“設計先行，編碼在後”，這樣纔能有效的避免突如其來的數據激增導致集羣處理能力不足引發的線上客戶檢索或者其他業務受到影響。
如何調優，正如問題 1 所說，這裏細化一下：
3.1 動態索引層面
基於模板+時間+rollover api 滾動創建索引，舉例：設計階段定義：blog 索引的模板格式爲：blog_index_時間戳的形式，每天遞增數據。這樣做的好處：不至於數據量激增導致單個索引數據量非常大，接近於上線 2 的32 次冪-1，索引存儲達到了 TB+甚至更大。
一旦單個索引很大，存儲等各種風險也隨之而來，所以要提前考慮+及早避免。
3.2 存儲層面
冷熱數據分離存儲，熱數據（比如最近 3 天或者一週的數據），其餘爲冷數據。
對於冷數據不會再寫入新數據，可以考慮定期 force_merge 加 shrink 壓縮操作，節省存儲空間和檢索效率。
3.3 部署層面
一旦之前沒有規劃，這裏就屬於應急策略。
結合 ES 自身的支持動態擴展的特點，動態新增機器的方式可以緩解集羣壓力，注意：如果之前主節點等規劃合理，不需要重啓集羣也能完成動態新增的。
4、elasticsearch 是如何實現 master 選舉的
面試官：想了解 ES 集羣的底層原理，不再只關注業務層面了。
解答：
前置前提：
（1）只有候選主節點（master：true）的節點才能成爲主節點。
（2）最小主節點數（min_master_nodes）的目的是防止腦裂。
覈對了一下代碼，核心入口爲 findMaster，選擇主節點成功返回對應 Master，否則返回 null。選舉流程大致描述如下：
第一步：確認候選主節點數達標，elasticsearch.yml 設置的值
discovery.zen.minimum_master_nodes；
第二步：比較：先判定是否具備 master 資格，具備候選主節點資格的優先返回；
若兩節點都爲候選主節點，則 id 小的值會主節點。注意這裏的 id 爲 string 類型。
題外話：獲取節點 id 的方法。
1GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name
2ip port heapPercent heapMax id name
詳細描述一下 Elasticsearch 索引文檔的過程
面試官：想了解 ES 的底層原理，不再只關注業務層面了。
解答：
這裏的索引文檔應該理解爲文檔寫入 ES，創建索引的過程。
文檔寫入包含：單文檔寫入和批量 bulk 寫入，這裏只解釋一下：單文檔寫入流程。
記住官方文檔中的這個圖。
第一步：客戶寫集羣某節點寫入數據，發送請求。（如果沒有指定路由/協調節點，請求的節點扮演路由節點的角色。）
第二步：節點 1 接受到請求後，使用文檔_id 來確定文檔屬於分片 0。請求會被轉到另外的節點，假定節點 3。因此分片 0 的主分片分配到節點 3 上。
第三步：節點 3 在主分片上執行寫操作，如果成功，則將請求並行轉發到節點 1和節點 2 的副本分片上，等待結果返回。所有的副本分片都報告成功，節點 3 將向協調節點（節點 1）報告成功，節點 1 向請求客戶端報告寫入成功。
如果面試官再問：第二步中的文檔獲取分片的過程？
回答：藉助路由算法獲取，路由算法就是根據路由和文檔 id 計算目標的分片 id 的過程。
1shard = hash(_routing) % (num_of_primary_shards)
詳細描述一下 Elasticsearch 搜索的過程？
面試官：想了解 ES 搜索的底層原理，不再只關注業務層面了。
解答：
搜索拆解爲“query then fetch” 兩個階段。
query 階段的目的：定位到位置，但不取。
步驟拆解如下：
（1）假設一個索引數據有 5 主+1 副本 共 10 分片，一次請求會命中（主或者副本分片中）的一個。
（2）每個分片在本地進行查詢，結果返回到本地有序的優先隊列中。
（3）第 2）步驟的結果發送到協調節點，協調節點產生一個全局的排序列表。
fetch 階段的目的：取數據。
路由節點獲取所有文檔，返回給客戶端。
Elasticsearch 在部署時，對 Linux 的設置有哪些優化方法
面試官：想了解對 ES 集羣的運維能力。
解答：
（1）關閉緩存 swap;
（2）堆內存設置爲：Min（節點內存/2, 32GB）;
（3）設置最大文件句柄數；
（4）線程池+隊列大小根據業務需要做調整；
（5）磁盤存儲 raid 方式——存儲有條件使用 RAID10，增加單節點性能以及避免單節點存儲故障。
lucence 內部結構是什麼？
面試官：想了解你的知識面的廣度和深度。
解答：
Lucene 是有索引和搜索的兩個過程，包含索引創建，索引，搜索三個要點。可以基於這個脈絡展開一些。
11、客戶端在和集羣連接時，如何選擇特定的節點執行請求的？
TransportClient 利用 transport 模塊遠程連接一個 elasticsearch 集羣。它並不加入到集羣中，只是簡單的獲得一個或者多個初始化的 transport 地址，並以 輪詢 的方式與這些地址進行通信。
12、詳細描述一下 Elasticsearch 索引文檔的過程。
協調節點默認使用文檔 ID 參與計算（也支持通過 routing），以便爲路由提供合適的分片。
shard = hash(document_id) % (num_of_primary_shards)複製代碼
（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）時；
補充：關於 Lucene 的 Segement：
（1）Lucene 索引是由多個段組成，段本身是一個功能齊全的倒排索引。
（2）段是不可變的，允許 Lucene 將新的文檔增量地添加到索引中，而不用從頭重建索引。
（3）對於每一個搜索請求而言，索引中的所有段都會被搜索，並且每個段會消耗CPU 的時鐘周、文件句柄和內存。這意味着段的數量越多，搜索性能會越低。
（4）爲了解決這個問題，Elasticsearch 會合並小段到一個較大的段，提交新的合併段到磁盤，並刪除那些舊的小段。