前言

隨著企業對近實時搜尋的迫切需求，Elasticsearch 受到越來越多的關注，無論是阿里、騰訊、京東等網際網路企業，還是平安、順豐等傳統企業都對 Elasticsearch 有廣泛的使用，但是在 Elasticsearch 6.8 釋出以前，大部分 Elasticsearch 功能都是付費的，開源版本的 Elasticsearch 在叢集管控方面能力有限，鑑於此，通用的實施方案就是給 Elasticsearch 新增一層閘道器，從而實現對 Elasticsearch 的管控。

小編分享的這份Java後端開發面試總結包含了JavaOOP、Java集合容器、Java異常、併發程式設計、Java反射、Java序列化、JVM、Redis、Spring MVC、MyBatis、MySQL資料庫、訊息中介軟體MQ、Dubbo、Linux、ZooKeeper、 分散式&資料結構與演算法等26個專題技術點，都是小編在各個大廠總結出來的面試真題，已經有很多粉絲靠這份PDF拿下眾多大廠的offer，今天在這裡總結分享給到大家！【已完結】

完整版Java面試題地址：2021最新面試題合集集錦。

Elasticsearch面試題

1、elasticsearch 瞭解多少，說說你們公司 es 的叢集架構，索引資料大小，分片有多少，以及一些調優手段 。

• 面試官：想了解應聘者之前公司接觸的 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 階段充分結合各個欄位的屬性，是否需要檢索、是否需要儲存等。

1.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、其他調優

• 部署調優，業務調優等。
• 上面的提及一部分，面試者就基本對你之前的實踐或者運維經驗有所評估了。

2、elasticsearch 的倒排索引是什麼

lucene 從 4+版本後開始大量使用的資料結構是 FST。FST 有兩個優點：

（1）空間佔用小。通過對詞典中單詞字首和字尾的重複利用，壓縮了儲存空間；

（2）查詢速度快。O(len(str))的查詢時間複雜度。

3、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 選舉的

1GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name
2ip port heapPercent heapMax id name複製程式碼

5、詳細描述一下 Elasticsearch 索引文件的過程

6、詳細描述一下 Elasticsearch 搜尋的過程？

面試官：想了解 ES 搜尋的底層原理，不再只關注業務層面了。

解答：

搜尋拆解為“query then fetch” 兩個階段。

query 階段的目的：定位到位置，但不取。

步驟拆解如下：

（1）假設一個索引資料有 5 主+1 副本 共 10 分片，一次請求會命中（主或者副本分片中）的一個。

（2）每個分片在本地進行查詢，結果返回到本地有序的優先佇列中。

（3）第 2）步驟的結果傳送到協調節點，協調節點產生一個全域性的排序列表。

fetch 階段的目的：取資料。

路由節點獲取所有文件，返回給客戶端。

7、Elasticsearch 在部署時，對 Linux 的設定有哪些優化方法

面試官：想了解對 ES 叢集的運維能力。

解答：

（1）關閉快取 swap;

（2）堆記憶體設定為：Min（節點記憶體/2, 32GB）;

（3）設定最大檔案控制代碼數；

（4）執行緒池+佇列大小根據業務需要做調整；

（5）磁碟儲存 raid 方式——儲存有條件使用 RAID10，增加單節點效能以及避免單節點儲存故障。

8、lucence 內部結構是什麼？

面試官：想了解你的知識面的廣度和深度。

解答：

Lucene 是有索引和搜尋的兩個過程，包含索引建立，索引，搜尋三個要點。可以基於這個脈絡展開一些。

9、Elasticsearch 是如何實現 Master 選舉的？

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

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

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

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

10、Elasticsearch 中的節點（比如共 20 個），其中的 10 個

選了一個 master，另外 10 個選了另一個 master，怎麼辦？

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

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

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

TransportClient 利用 transport 模組遠端連線一個 elasticsearch 叢集。它並不加入到叢集中，只是簡單的獲得一個或者多個初始化的 transport 地址，並以 輪詢 的方式與這些地址進行通訊。

12、詳細描述一下 Elasticsearch 索引文件的過程。

協調節點預設使用文件 ID 參與計算（也支援通過 routing），以便為路由提供合適的分片

shard = hash(document_id) % (num_of_primary_shards)複製程式碼

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

（2）當然在某些情況下，存在 Momery Buffffer 和 Filesystem Cache 的資料可能會丟失，ES 是通過translog 的機制來保證資料的可靠性的。其實現機制是接收到請求後，同時也會寫入到 translog 中 ， 當 Filesystem cache 中的資料寫入到磁碟中時，才會清除掉，這個過程叫做 flflush；

（3）在 flflush 過程中，記憶體中的緩衝將被清除，內容被寫入一個新段，段的 fsync將建立一個新的提交點，並將內容重新整理到磁碟，舊的 translog 將被刪除並開始一個新的 translog。

（4）flflush 觸發的時機是定時觸發（預設 30 分鐘）或者 translog 變得太大（預設為 512M）時；補充：關於 Lucene 的 Segement：

（1）Lucene 索引是由多個段組成，段本身是一個功能齊全的倒排索引。

（2）段是不可變的，允許 Lucene 將新的文件增量地新增到索引中，而不用從頭重建索引。

（3）對於每一個搜尋請求而言，索引中的所有段都會被搜尋，並且每個段會消耗CPU 的時鐘周、檔案控制代碼和記憶體。這意味著段的數量越多，搜尋效能會越低。

（4）為了解決這個問題，Elasticsearch 會合並小段到一個較大的段，提交新的合併段到磁碟，並刪除那些舊的小段。

13、Elasticsearch 是一個分散式的 RESTful 風格的搜尋和資料分析引擎。

（1）查詢 ： Elasticsearch 允許執行和合並多種型別的搜尋 — 結構化、非結構化、地理位置、度量指標 — 搜尋方式隨心而變。

（2）分析 ： 找到與查詢最匹配的十個文件是一回事。但是如果面對的是十億行日誌，又該如何解讀呢？Elasticsearch 聚合讓您能夠從大處著眼，探索資料的趨勢和模式。

（3）速度 ： Elasticsearch 很快。真的，真的很快。

（4）可擴充套件性 ： 可以在膝上型電腦上執行。 也可以在承載了 PB 級資料的成百上千臺伺服器上執行。

（5）彈性 ： Elasticsearch 執行在一個分散式的環境中，從設計之初就考慮到了這一點。

（6）靈活性 ： 具備多個案例場景。數字、文字、地理位置、結構化、非結構化。所有的資料型別都歡迎。

（7）HADOOP & SPARK ： Elasticsearch + Hadoop

14、Elasticsearch是一個高度可伸縮的開源全文搜尋和分析引擎。它允許您快速和接近實時地儲存、搜尋和分析大量資料。

這裡有一些使用Elasticsearch的用例：

（1）你經營一個網上商店，你允許你的顧客搜尋你賣的產品。在這種情況下，您可以使用Elasticsearch來儲存整個產品目錄和庫存，併為它們提供搜尋和自動完成建議。

（2）你希望收集日誌或事務資料，並希望分析和挖掘這些資料，以查詢趨勢、統計、彙總或異常。在這種情況下，你可以使用loghide (Elasticsearch/ loghide /Kibana堆疊的一部分)來收集、聚合和解析資料，然後讓loghide將這些資料輸入到Elasticsearch中。一旦資料在Elasticsearch中，你就可以執行搜尋和聚合來挖掘你感興趣的任何資訊。

（3）你執行一個價格警報平臺，允許精通價格的客戶指定如下規則:“我有興趣購買特定的電子裝置，如果下個月任何供應商的產品價格低於X美元，我希望得到通知”。在這種情況下，你可以抓取供應商的價格，將它們推入到Elasticsearch中，並使用其反向搜尋(Percolator)功能來匹配價格走勢與客戶查詢，並最終在找到匹配後將警報推送給客戶。

（4）你有分析/業務智慧需求，並希望快速調查、分析、視覺化，並對大量資料提出特別問題(想想數百萬或數十億的記錄)。在這種情況下，你可以使用Elasticsearch來儲存資料，然後使用Kibana (Elasticsearch/ loghide /Kibana堆疊的一部分)來構建自定義儀表板，以視覺化對您來說很重要的資料的各個方面。此外，還可以使用Elasticsearch聚合功能對資料執行復雜的業務智慧查詢。

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

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

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

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

16、詳細描述一下 Elasticsearch 搜尋的過程。

17、在 Elasticsearch 中，是怎麼根據一個詞找到對應的倒排索引的？

（1）Lucene的索引過程，就是按照全文檢索的基本過程，將倒排表寫成此檔案格式的過程。

（2）Lucene的搜尋過程，就是按照此檔案格式將索引進去的資訊讀出來，然後計算每篇文件打分(score)的過程。

18、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。

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

（1）倒排詞典的索引需要常駐記憶體，無法 GC，需要監控 data node 上 segmentmemory 增長趨勢。

（2）各類快取，fifield cache, fifilter cache, indexing cache, bulk queue 等等，要設定合理的大小，並且要應該根據最壞的情況來看 heap 是否夠用，也就是各類快取全部佔滿的時候，還有 heap 空間可以分配給其他任務嗎？避免採用 clear cache等“自欺欺人”的方式來釋放記憶體。

（3）避免返回大量結果集的搜尋與聚合。確實需要大量拉取資料的場景，可以採用scan & scroll api來實現。

（4）cluster stats 駐留記憶體並無法水平擴充套件，超大規模叢集可以考慮分拆成多個叢集通過 tribe node連線。

（5）想知道 heap 夠不夠，必須結合實際應用場景，並對叢集的 heap 使用情況做持續的監控。

（6）根據監控資料理解記憶體需求，合理配置各類circuit breaker，將記憶體溢位風險降低到最低

20、Elasticsearch 對於大資料量（上億量級）的聚合如何實現？

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

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

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

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

（3）對於讀操作，可以設定 replication 為 sync(預設)，這使得操作在主分片和副本分片都完成後才會返回；如果設定 replication 為 async 時，也可以通過設定搜尋請求引數_preference 為 primary 來查

詢主分片，確保文件是最新版本。

22、如何監控 Elasticsearch 叢集狀態？

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

23、介紹下你們電商搜尋的整體技術架構。

24、介紹一下你們的個性化搜尋方案？

基於word2vec和Elasticsearch實現個性化搜尋

（1）基於word2vec、Elasticsearch和自定義的指令碼外掛，我們就實現了一個個性化的搜尋服務，相對於原有的實現，新版的點選率和轉化率都有大幅的提升；

（2）基於word2vec的商品向量還有一個可用之處，就是可以用來實現相似商品的推薦；

（3）使用word2vec來實現個性化搜尋或個性化推薦是有一定侷限性的，因為它只能處理使用者點選歷史這樣的時序資料，而無法全面的去考慮使用者偏好，這個還是有很大的改進和提升的空間；

25、是否瞭解字典樹？

常用字典資料結構如下所示：

Trie 的核心思想是空間換時間，利用字串的公共字首來降低查詢時間的開銷以達到提高效率的目的。

它有 3 個基本性質：

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

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

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

或者用陣列來模擬動態。而空間的花費，不會超過單詞數×單詞長度。

（2）實現：對每個結點開一個字母集大小的陣列，每個結點掛一個連結串列，使用左兒子右兄弟表示法記

錄這棵樹；

（3）對於中文的字典樹，每個節點的子節點用一個雜湊表儲存，這樣就不用浪費太大的空間，而且查

詢速度上可以保留雜湊的複雜度 O(1)

26、拼寫糾錯是如何實現的？

（1）拼寫糾錯是基於編輯距離來實現；編輯距離是一種標準的方法，它用來表示經過插入、刪除和替換操作從一個字串轉換到另外一個字串的最小操作步數；

（2）編輯距離的計算過程：比如要計算 batyu 和 beauty 的編輯距離，先建立一個7×8 的表（batyu長度為 5，coffffee 長度為 6，各加 2），接著，在如下位置填入黑色數字。其他格的計算過程是取以下

三個值的最小值：

如果最上方的字元等於最左方的字元，則為左上方的數字。否則為左上方的數字+1。（對於 3,3 來說為0）

左方數字+1（對於 3,3 格來說為 2）

上方數字+1（對於 3,3 格來說為 2）

最終取右下角的值即為編輯距離的值 3。