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、其他調優
部署調優，業務調優等。
上面的提及一部分，面試者就基本對你之前的實踐或者運維經驗有所評估了。

elasticsearch 的倒排索引是什么

面試官：想了解你對基礎概念的認知。
解答：通俗解釋一下就可以。
傳統的我們的檢索是通過文章，逐個遍歷找到對應關鍵詞的位置。
而倒排索引，是通過分詞策略，形成了詞和文章的映射關系表，這種詞典+映射表即為倒排索引。有了倒排索引，就能實現 o（1）時間復雜度的效率檢索文章了，極大的提高了檢索效率。

學術的解答方式：
倒排索引，相反于一篇文章包含了哪些詞，它從詞出發，記載了這個詞在哪些文檔中出現過，由兩部分組成——詞典和倒排表。
加分項：倒排索引的底層實現是基于：FST（Finite State Transducer）數據結構。
lucene 從 4+版本后開始大量使用的數據結構是 FST。FST 有兩個優點：
（1）空間占用小。通過對詞典中單詞前綴和后綴的重復利用，壓縮了存儲空間；
（2）查詢速度快。O(len(str))的查詢時間復雜度。

elasticsearch 索引數據多了怎么辦，如何調優，部署

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

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 的方法。

GET/_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name2ipportheapPercentheapMaxidname

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

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

解答：
這里的索引文檔應該理解為文檔寫入 ES，創建索引的過程。
文檔寫入包含：單文檔寫入和批量 bulk 寫入，這里只解釋一下：單文檔寫入流程。
記住官方文檔中的這個圖。

第一步：客戶寫集群某節點寫入數據，發送請求。（如果沒有指定路由/協調節點，請求的節點扮演路由節點的角色。）
第二步：節點 1 接受到請求后，使用文檔_id 來確定文檔屬于分片 0。請求會被轉到另外的節點，假定節點 3。因此分片 0 的主分片分配到節點 3 上。
第三步：節點 3 在主分片上執行寫操作，如果成功，則將請求并行轉發到節點 1和節點 2 的副本分片上，等待結果返回。所有的副本分片都報告成功，節點 3 將向協調節點（節點 1）報告成功，節點 1 向請求客戶端報告寫入成功。
如果面試官再問：第二步中的文檔獲取分片的過程？
回答：借助路由算法獲取，路由算法就是根據路由和文檔 id 計算目標的分片 id 的過程。

shard=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 是有索引和搜索的兩個過程，包含索引創建，索引，搜索三個要點。可以基于這個脈絡展開一些。

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 功能。

Elasticsearch 中的節點（比如共 20 個），其中的 10 個選了一個 master，另外 10 個選了另一個 master，怎么辦？

（1）當集群 master 候選數量不小于 3 個時，可以通過設置最少投票通過數量（discovery.zen.minimum_master_nodes）超過所有候選節點一半以上來解決腦裂問題；
（2）當候選數量為兩個時，只能修改為唯一的一個 master 候選，其他作為 data節點，避免腦裂問題。

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

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

詳細描述一下 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 會合并小段到一個較大的段，提交新的合并段到磁盤，并刪除那些舊的小段。

總結

以上是生活随笔為你收集整理的Elasticsearch原理与调优的全部內容，希望文章能夠幫你解決所遇到的問題。

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