分布式搜尋引擎elasticsearch面試總結

大家好，我是瓜哥：

當前公司日誌平臺中日誌相關存儲和搜索採用了Elasticsearch，Elastic 的底層是開源庫 Lucene。但是，你沒法直接用 Lucene，必須自己寫代碼去調用它的接口。Elastic 是 Lucene 的封裝，提供了 REST API 的操作接口，開箱即用。

ElasticSearch在大型互聯網公司的使用是非常廣泛的，有ElasticSearch相關項目開發經驗可以對自己的薪資提升是非常有幫助的，下面是本人總結的面試過程當中常會用問到的相關問題，麻煩各位評論點贊。

一、Elasticsearch監控的常用工具

我大概用過如下的監控插件（注意此處插件的版本，不同es的版本，監控工具的安裝方式可能不一樣）

1. bigdesk 統計分析和圖表化elasticsearch的集群信息狀態

http://blog.csdn.net/yangwenbo214/article/details/74000458

1. head 能清晰看到每個分片的信息、發送rest api請求。注意安裝版本要求

https://github.com/mobz/elasticsearch-head

1. marvel 5.*版本後集成到x-pack中了，是收費的

https://www.elastic.co/guide/en/x-pack/current/xpack-introduction.html

1. kopf 也是web形式，有點像head

https://github.com/lmenezes/elasticsearch-kopf

一般head和x-pack比較常用。head的安裝在5.*中比較繁瑣，需要注意

二、Elasticsearch是如何實現Master選舉的

1. Elasticsearch的選主是ZenDiscovery模塊負責的，主要包含Ping（節點之間通過這個RPC來發現彼此）和Unicast（單播模塊包含一個主機列表以控制哪些節點需要ping通）這兩部分；
2. 對所有可以成為master的節點（node.master: true）根據nodeId字典排序，每次選舉每個節點都把自己所知道節點排一次序，然後選出第一個（第0位）節點，暫且認為它是master節點。
3. 如果對某個節點的投票數達到一定的值（可以成為master節點數n/2+1）並且該節點自己也選舉自己，那這個節點就是master。否則重新選舉一直到滿足上述條件。

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

三、Elasticsearch是如何避免腦裂現象的

1. 當集群中master候選的個數不小於3個（node.master:

true）。可以通過discovery.zen.minimum_master_nodes

這個參數的設置來避免腦裂，設置為(N/2)+1。

這裡node.master : true 是說明你是有資格成為master，並不是指你就是master。是皇子，不是皇帝。假如有10個皇子，這裡應該設置為（10/2）+1=6，這6個皇子合謀做決策，選出新的皇帝。另外的4個皇子，即使他們全聚一起也才四個人，不足合謀的最低人數限制，他們不能選出新皇帝。

假如discovery.zen.minimum_master_nodes 設置的個數為5，有恰好有10個master備選節點，會出現什麼情況呢？5個皇子組成一波，選一個皇帝出來，另外5個皇子也夠了人數限制，他們也能選出一個皇帝來。此時一個天下兩個皇帝，在es中就是腦裂。

1. 假如集群master候選節點為2的時候，這種情況是不合理的，最好把另外一個node.master改成false。如果我們不改節點設置，還是套上面的(N/2)+1公式，此時discovery.zen.minimum_master_nodes應該設置為2。這就出現一個問題，兩個master備選節點，只要有一個掛，就選不出master了。

我還是用皇子的例子來說明。假如先皇在位的時候規定，必須他的兩個皇子都在的時候，才能從中2選1 繼承皇位。萬一有個皇子出意外掛掉了，就剩下一個皇子，天下不就沒有新皇帝了麼。

三、客戶端在和集群連接時，如何選擇特定的節點執行請求的？

1. TransportClient利用transport模塊遠程連接一個elasticsearch集群。它並不加入到集群中，只是簡單的獲得一個或者多個初始化的transport地址，並以 輪詢 的方式與這些地址進行通信。

想了解該處，可以參考各個編程語言提供的es 庫

四、Elasticsearch 文檔索引過程描述

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

shard = hash(document_id) % (num_of_primary_shards)

1. 當分片所在的節點接收到來自協調節點的請求後，會將請求寫入到Memory Buffer，然後定時（默認是每隔1秒）寫入到Filesystem Cache，這個從Momery Buffer到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（也就是上文中所說的段）的補充：

• Lucene索引是由多個段組成，段本身是一個功能齊全的倒排索引。
• 段是不可變的，允許Lucene將新的文檔增量地添加到索引中，而不用從頭重建索引。
• 對於每一個搜索請求而言，索引中的所有段都會被搜索，並且每個段會消耗CPU的時鐘周、文件句柄和內存。這意味著段的數量越多，搜索性能會越低。
• 為了解決這個問題，Elasticsearch會合並小段到一個較大的段，提交新的合併段到磁盤，並刪除那些舊的小段

五、Elasticsearch 文檔更新和刪除過程描述

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

六、Elasticsearch搜索的過程描述

1. 搜索被執行成一個兩階段過程，我們稱之為 Query Then Fetch
2. 在初始查詢階段時，查詢會廣播到索引中每一個分片拷貝（主分片或者副本分片）。 每個分片在本地執行搜索並構建一個匹配文檔的大小為 from + size 的優先隊列。PS：在搜索的時候是會查詢Filesystem Cache的，但是有部分數據還在Memory Buffer，所以搜索是近實時的。
3. 每個分片返回各自優先隊列中 所有文檔的 ID 和排序值 給協調節點，它合併這些值到自己的優先隊列中來產生一個全局排序後的結果列表。
4. 接下來就是 取回階段，協調節點辨別出哪些文檔需要被取回並向相關的分片提交多個 GET 請求。每個分片加載並豐富文檔，如果有需要的話，接著返回文檔給協調節點。一旦所有的文檔都被取回了，協調節點返回結果給客戶端。

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

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

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

八、Elasticsearch在部署時，對Linux的設置有哪些優化方法？

1. 64 GB 內存的機器是非常理想的， 但是32 GB 和16 GB 機器也是很常見的。少於8 GB 會適得其反。
2. 如果你要在更快的 CPUs 和更多的核心之間選擇，選擇更多的核心更好。多個內核提供的額外併發遠勝過稍微快一點點的時鐘頻率。
3. 如果你負擔得起 SSD，它將遠遠超出任何旋轉介質。 基於 SSD 的節點，查詢和索引性能都有提升。如果你負擔得起，SSD 是一個好的選擇。
4. 即使數據中心們近在咫尺，也要避免集群跨越多個數據中心。絕對要避免集群跨越大的地理距離。
5. 請確保運行你應用程序的 JVM 和服務器的 JVM 是完全一樣的。 在 Elasticsearch 的幾個地方，使用 Java 的本地序列化。
6. 通過設置gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time可以在集群重啟的時候避免過多的分片交換，這可能會讓數據恢復從數個小時縮短為幾秒鐘。
7. Elasticsearch 默認被配置為使用單播發現，以防止節點無意中加入集群。只有在同一臺機器上運行的節點才會自動組成集群。最好使用單播代替組播。
8. 不要隨意修改垃圾回收器（CMS）和各個線程池的大小。
9. 把你的內存的（少於）一半給 Lucene（但不要超過 32 GB！），通過ES_HEAP_SIZE 環境變量設置。
10. 內存交換到磁盤對服務器性能來說是致命的。如果內存交換到磁盤上，一個 100 微秒的操作可能變成 10 毫秒。 再想想那麼多 10 微秒的操作時延累加起來。 不難看出 swapping 對於性能是多麼可怕。
11. Lucene 使用了大量的文件。同時，Elasticsearch 在節點和 HTTP 客戶端之間進行通信也使用了大量的套接字。 所有這一切都需要足夠的文件描述符。你應該增加你的文件描述符，設置一個很大的值，如 64,000。

補充：索引階段性能提升方法

1. 使用批量請求並調整其大小：每次批量數據 5–15 MB 大是個不錯的起始點。
2. 段和段合併：Elasticsearch 默認值是 20 MB/s，對機械磁盤應該是個不錯的設置。如果你用的是 SSD，可以考慮提高到 100–200 MB/s。如果你在做批量導入，完全不在意搜索，你可以徹底關掉合併限流。另外還可以增加 index.translog.flush_threshold_size 設置，從默認的 512 MB 到更大一些的值，比如 1 GB，這可以在一次清空觸發的時候在事務日誌裡積累出更大的段。
3. 如果你的搜索結果不需要近實時的準確度，考慮把每個索引的index.refresh_interval 改到30s。
4. 如果你在做大批量導入，考慮通過設置index.number_of_replicas: 0 關閉副本。

九、對於GC方面，在使用Elasticsearch時要注意什麼？

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

十、ElasticSearch分頁方式：

在ElasticSearch中實現分頁查詢的方式有兩種，分別為深度分頁(from-size)和快照分頁(scroll)

閱讀更多 分佈式系統架構 的文章

關鍵字: 日誌 編程語言 技術