總結一些ES相關的面試題，既是對日常工作所學知識的回顧與梳理，也可以查漏補缺。
題目來自於網絡，只整理一些我個人覺得還不錯的，有些答案是我根據自己的理解給出的，僅供參考。
既然是面試題，每個人都會有自己的結合業務場景的答案，沒有100分的標准的答案。
如果有不同的理解，歡迎大家在評論區留言指正，感謝大家！
1. 什么是Elasticsearch？
Elasticsearch 是一個基於 Lucene 的搜索引擎。它提供了具有 HTTP Web 界面和無架構 JSON 文檔的分布式，多租戶能力的全文搜索引擎。
Elasticsearch 是用 Java 開發的，根據 Apache 許可條款作為開源發布。
2.為什么要使用Elasticsearch?
因為在我們商城中的數據，將來會非常多，所以采用以往的模糊查詢，模糊查詢前綴匹配，索引失效，會放棄索引，導致商品查詢是全表掃面，在百萬級別的數據庫中，效率非常低下，而我們使用ES做一個全文索引，我們將經常查詢的商品的某些字段，比如說商品名，描述、價格還有id這些字段我們放入我們索引庫里，可以提高查詢速度。
2. ES中的倒排索引是什么？
傳統的檢索方式是通過文章，逐個遍歷找到對應關鍵詞的位置。
倒排索引，是通過分詞策略，形成了詞和文章的映射關系表，也稱倒排表，這種詞典 + 映射表即為倒排索引。
其中詞典中存儲詞元，倒排表中存儲該詞元在哪些文中出現的位置。
有了倒排索引，就能實現 O(1) 時間復雜度的效率檢索文章了，極大的提高了檢索效率。
加分項：
倒排索引的底層實現是基於：FST（Finite State Transducer有限狀態轉換器）數據結構。
Lucene 從 4+ 版本后開始大量使用的數據結構是 FST。FST 有兩個優點：
1）空間占用小。通過對詞典中單詞前綴和后綴的重復利用，壓縮了存儲空間；
2）查詢速度快。O(len(str)) 的查詢時間復雜度。
3. ES是如何實現master選舉的？
前置條件：
1）只有是候選主節點（master：true）的節點才能成為主節點。
2）最小主節點數（min_master_nodes）的目的是防止腦裂。
Elasticsearch 的選主是 ZenDiscovery 模塊負責的，主要包含 Ping（節點之間通過這個RPC來發現彼此）和 Unicast（單播模塊包含一個主機列表以控制哪些節點需要 ping 通）這兩部分；
獲取主節點的核心入口為 findMaster，選擇主節點成功返回對應 Master，否則返回 null。
選舉流程大致描述如下：
第一步：確認候選主節點數達標，elasticsearch.yml 設置的值 discovery.zen.minimum_master_nodes;
第二步：對所有候選主節點根據nodeId字典排序，每次選舉每個節點都把自己所知道節點排一次序，然后選出第一個（第0位）節點，暫且認為它是master節點。
第三步：如果對某個節點的投票數達到一定的值（候選主節點數n/2+1）並且該節點自己也選舉自己，那這個節點就是master。否則重新選舉一直到滿足上述條件。
- 補充：
- 這里的 id 為 string 類型。
- master 節點的職責主要包括集群、節點和索引的管理，不負責文檔級別的管理；data 節點可以關閉 http 功能。
4. 如何解決ES集群的腦裂問題
所謂集群腦裂，是指 Elasticsearch 集群中的節點（比如共 20 個），其中的 10 個選了一個 master，另外 10 個選了另一個 master 的情況。
當集群 master 候選數量不小於 3 個時，可以通過設置最少投票通過數量（discovery.zen.minimum_master_nodes）超過所有候選節點一半以上來解決腦裂問題；
當候選數量為兩個時，只能修改為唯一的一個 master 候選，其他作為 data 節點，避免腦裂問題。
5. 詳細描述一下ES索引文檔的過程？
這里的索引文檔應該理解為文檔寫入 ES，創建索引的過程。
第一步：客戶端向集群某節點寫入數據，發送請求。（如果沒有指定路由/協調節點，請求的節點扮演協調節點的角色。）
第二步：協調節點接受到請求后，默認使用文檔 ID 參與計算（也支持通過 routing），得到該文檔屬於哪個分片。隨后請求會被轉到另外的節點。
# 路由算法：根據文檔id或路由計算目標的分片id
shard = hash(document_id) % (num_of_primary_shards) 第三步：當分片所在的節點接收到來自協調節點的請求后，會將請求寫入到 Memory Buffer，然后定時（默認是每隔 1 秒）寫入到F ilesystem Cache，這個從 Momery Buffer 到 Filesystem Cache 的過程就叫做 refresh；
第四步：當然在某些情況下，存在 Memery Buffer 和 Filesystem Cache 的數據可能會丟失，ES 是通過 translog 的機制來保證數據的可靠性的。其實現機制是接收到請求后，同時也會寫入到 translog 中，當 Filesystem cache 中的數據寫入到磁盤中時，才會清除掉，這個過程叫做 flush；
第五步：在 flush 過程中，內存中的緩沖將被清除，內容被寫入一個新段，段的 fsync 將創建一個新的提交點，並將內容刷新到磁盤，舊的 translog 將被刪除並開始一個新的 translog。
第六步：flush 觸發的時機是定時觸發（默認 30 分鍾）或者 translog 變得太大（默認為 512 M）時。
- 補充：關於 Lucene 的 Segement
- Lucene 索引是由多個段組成，段本身是一個功能齊全的倒排索引。
- 段是不可變的，允許 Lucene 將新的文檔增量地添加到索引中，而不用從頭重建索引。
- 對於每一個搜索請求而言，索引中的所有段都會被搜索，並且每個段會消耗 CPU 的時鍾周、文件句柄和內存。這意味着段的數量越多，搜索性能會越低。
- 為了解決這個問題，Elasticsearch 會合並小段到一個較大的段，提交新的合並段到磁盤，並刪除那些舊的小段。（段合並）
6. 詳細描述一下ES更新和刪除文檔的過程？
刪除和更新也都是寫操作，但是 Elasticsearch 中的文檔是不可變的，因此不能被刪除或者改動以展示其變更。
磁盤上的每個段都有一個相應的 .del 文件。當刪除請求發送后，文檔並沒有真的被刪除，而是在 .del 文件中被標記為刪除。該文檔依然能匹配查詢，但是會在結果中被過濾掉。當段合並時，在 .del 文件中被標記為刪除的文檔將不會被寫入新段。
在新的文檔被創建時，Elasticsearch 會為該文檔指定一個版本號，當執行更新時，舊版本的文檔在 .del 文件中被標記為刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結果中被過濾掉。
7. 詳細描述一下ES搜索的過程？
搜索被執行成一個兩階段過程，即 Query Then Fetch；
Query階段：
查詢會廣播到索引中每一個分片拷貝（主分片或者副本分片）。每個分片在本地執行搜索並構建一個匹配文檔的大小為 from + size 的優先隊列。PS：在搜索的時候是會查詢Filesystem Cache的，但是有部分數據還在Memory Buffer，所以搜索是近實時的。
每個分片返回各自優先隊列中 所有文檔的 ID 和排序值 給協調節點，它合並這些值到自己的優先隊列中來產生一個全局排序后的結果列表。
Fetch階段：
協調節點辨別出哪些文檔需要被取回並向相關的分片提交多個 GET 請求。每個分片加載並 豐富 文檔，如果有需要的話，接着返回文檔給協調節點。一旦所有的文檔都被取回了，協調節點返回結果給客戶端。
8. 在並發情況下，ES如果保證讀寫一致？
可以通過版本號使用樂觀並發控制，以確保新版本不會被舊版本覆蓋，由應用層來處理具體的沖突；
另外對於寫操作，一致性級別支持quorum/one/all，默認為quorum，即只有當大多數分片可用時才允許寫操作。但即使大多數可用，也可能存在因為網絡等原因導致寫入副本失敗，這樣該副本被認為故障，分片將會在一個不同的節點上重建。
對於讀操作，可以設置replication為sync(默認)，這使得操作在主分片和副本分片都完成后才會返回；如果設置replication為async時，也可以通過設置搜索請求參數_preference為primary來查詢主分片，確保文檔是最新版本。
9. ES對於大數據量（上億量級）的聚合如何實現？
Elasticsearch 提供的首個近似聚合是cardinality 度量。它提供一個字段的基數，即該字段的distinct或者unique值的數目。它是基於HLL算法的。HLL 會先對我們的輸入作哈希運算，然后根據哈希運算的結果中的 bits 做概率估算從而得到基數。其特點是：可配置的精度，用來控制內存的使用（更精確 ＝ 更多內存）；小的數據集精度是非常高的；我們可以通過配置參數，來設置去重需要的固定內存使用量。無論數千還是數十億的唯一值，內存使用量只與你配置的精確度相關。
10. 對於GC方面，在使用ES時要注意什么？
1）倒排詞典的索引需要常駐內存，無法GC，需要監控data node上segment memory增長趨勢。
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使用情況做持續的監控。
11. 說說你們公司ES的集群架構，索引數據大小，分片有多少，以及一些調優手段？
根據實際情況回答即可，如果是我的話會這么回答：
我司有多個ES集群，下面列舉其中一個。該集群有20個節點，根據數據類型和日期分庫，每個索引根據數據量分片，比如日均1億+數據的，控制單索引大小在200GB以內。
下面重點列舉一些調優策略，僅是我做過的，不一定全面，如有其它建議或者補充歡迎留言。
部署層面：
1）最好是64GB內存的物理機器，但實際上32GB和16GB機器用的比較多，但絕對不能少於8G，除非數據量特別少，這點需要和客戶方面溝通並合理說服對方。
2）多個內核提供的額外並發遠勝過稍微快一點點的時鍾頻率。
3）盡量使用SSD，因為查詢和索引性能將會得到顯著提升。
4）避免集群跨越大的地理距離，一般一個集群的所有節點位於一個數據中心中。
5）設置堆內存：節點內存/2，不要超過32GB。一般來說設置export ES_HEAP_SIZE=32g環境變量，比直接寫-Xmx32g -Xms32g更好一點。
6）關閉緩存swap。內存交換到磁盤對服務器性能來說是致命的。如果內存交換到磁盤上，一個100微秒的操作可能變成10毫秒。 再想想那么多10微秒的操作時延累加起來。不難看出swapping對於性能是多么可怕。
7）增加文件描述符，設置一個很大的值，如65535。Lucene使用了大量的文件，同時，Elasticsearch在節點和HTTP客戶端之間進行通信也使用了大量的套接字。所有這一切都需要足夠的文件描述符。
8）不要隨意修改垃圾回收器（CMS）和各個線程池的大小。
9）通過設置gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time可以在集群重啟的時候避免過多的分片交換，這可能會讓數據恢復從數個小時縮短為幾秒鍾。
索引層面：
1）使用批量請求並調整其大小：每次批量數據 5–15 MB 大是個不錯的起始點。
2）段合並：Elasticsearch默認值是20MB/s，對機械磁盤應該是個不錯的設置。如果你用的是SSD，可以考慮提高到100-200MB/s。如果你在做批量導入，完全不在意搜索，你可以徹底關掉合並限流。另外還可以增加 index.translog.flush_threshold_size 設置，從默認的512MB到更大一些的值，比如1GB，這可以在一次清空觸發的時候在事務日志里積累出更大的段。
3）如果你的搜索結果不需要近實時的准確度，考慮把每個索引的index.refresh_interval 改到30s。
4）如果你在做大批量導入，考慮通過設置index.number_of_replicas: 0 關閉副本。
5）需要大量拉取數據的場景，可以采用scan & scroll api來實現，而不是from/size一個大范圍。
存儲層面：
1）基於數據+時間滾動創建索引，每天遞增數據。控制單個索引的量，一旦單個索引很大，存儲等各種風險也隨之而來，所以要提前考慮+及早避免。
2）冷熱數據分離存儲，熱數據（比如最近3天或者一周的數據），其余為冷數據。對於冷數據不會再寫入新數據，可以考慮定期force_merge加shrink壓縮操作，節省存儲空間和檢索效率。