elasticsearch 面試總結（一）

es 讀數據過程

可以通過 doc id 來查詢，會根據 doc id 進行 hash，判斷出來當時把 doc id 分配到了哪個 shard 上面去，從那個 shard 去查詢。

• 客戶端發送請求到任意一個 node，成為 coordinate node。

• coordinate node 對 doc id 進行哈希路由，將請求轉發到對應的 node，此時會使用 round-robin隨機輪詢算法，在 primary shard 以及其所有 replica 中隨機選擇一個，讓讀請求負載均衡。

• 接收請求的 node 返回 document 給 coordinate node。

• coordinate node 返回 document 給客戶端。

• es 讀數據過程

  可以通過 doc id 來查詢，會根據 doc id 進行 hash，判斷出來當時把 doc id 分配到了哪個 shard 上面去，從那個 shard 去查詢。

  • 客戶端發送請求到任意一個 node，成為 coordinate node。

  • coordinate node 對 doc id 進行哈希路由，將請求轉發到對應的 node，此時會使用 round-robin隨機輪詢算法，在 primary shard 以及其所有 replica 中隨機選擇一個，讓讀請求負載均衡。

  • 接收請求的 node 返回 document 給 coordinate node。

  • coordinate node 返回 document 給客戶端。

  寫請求是寫入 primary shard，然后同步給所有的 replica shard；讀請求可以從 primary shard 或 replica shard 讀取，采用的是隨機輪詢算法

 

寫數據底層原理

 

 

 

1）document先寫入導內存buffer中，同時寫translog日志

 

2)）https://www.elastic.co/guide/cn/elasticsearch/guide/current/near-real-time.html

 

refresh操作所以近實時搜索：寫入和打開一個新段(一個追加的倒排索引)的輕量的過程叫做 refresh 。每隔一秒鍾把buffer中的數據創建一個新的segment，這里新段會被先寫入到文件系統緩存--這一步代價會比較低，稍后再被刷新到磁盤--這一步代價比較高。不過只要文件已經在緩存中， 就可以像其它文件一樣被打開和讀取了，內存buffer被清空。此時，新segment 中的文件就可以被搜索了，這就意味着document從被寫入到可以被搜索需要一秒種，如果要更改這個屬性，可以執行以下操作

 

PUT /my_index
{
  "settings": {
    "refresh_interval": "30s" 
  }
}
3）https://www.elastic.co/guide/cn/elasticsearch/guide/current/translog.html

 

flush操作導致持久化變更：執行一個提交並且截斷 translog 的行為在 Elasticsearch 被稱作一次 flush。刷新（refresh）完成后, 緩存被清空但是事務日志不會。translog日志也會越來越多，當translog日志大小大於一個閥值時候或30分鍾，會出發flush操作。

 

• 所有在內存緩沖區的文檔都被寫入一個新的段。
• 緩沖區被清空。
• 一個提交點被寫入硬盤。（表明有哪些segment commit了）
• 文件系統緩存通過 fsync 到磁盤。
• 老的 translog 被刪除。

 

分片每30分鍾被自動刷新（flush），或者在 translog 太大的時候也會刷新。也可以用_flush命令手動執行。

 

translog每隔5秒會被寫入磁盤（所以如果這5s，數據在cache而且log沒持久化會丟失）。在一次增刪改操作之后translog只有在replica和primary shard都成功才會成功，如果要提高操作速度，可以設置成異步的

 

PUT /my_index
{
  "settings": {
    "index.translog.durability": "async" ,

 

    "index.translog.sync_interval":"5s"
  }
}

 

所以總結是有三個批次操作，一秒做一次refresh保證近實時搜索，5秒做一次translog持久化保證數據未持久化前留底，30分鍾做一次數據持久化。

 

2.基於translog和commit point的數據恢復

 

在磁盤上會有一個上次持久化的commit point，translog上有一個commit point，根據這兩個commit point，會把translog中的變更記錄進行回放，重新執行之前的操作

 

3.不變形下的刪除和更新原理

 

https://www.elastic.co/guide/cn/elasticsearch/guide/current/dynamic-indices.html#deletes-and-updates

 

一個文檔被 “刪除” 時，它實際上只是在 .del 文件中被 標記 刪除。一個被標記刪除的文檔仍然可以被查詢匹配到， 但它會在最終結果被返回前從結果集中移除。

 

文檔更新也是類似的操作方式：當一個文檔被更新時，舊版本文檔被標記刪除，文檔的新版本被索引到一個新的段中。 可能兩個版本的文檔都會被一個查詢匹配到，但被刪除的那個舊版本文檔在結果集返回前就已經被移除。

 

段合並的時候會將那些舊的已刪除文檔 從文件系統中清除。 被刪除的文檔（或被更新文檔的舊版本）不會被拷貝到新的大段中。

 

4.merge操作，段合並

https://www.elastic.co/guide/cn/elasticsearch/guide/current/merge-process.html

由於每秒會把buffer刷到segment中，所以segment會很多，為了防止這種情況出現，es內部會不斷把一些相似大小的segment合並，並且物理刪除del的segment。

當然也可以手動執行

POST /my_index/_optimize?max_num_segments=1，盡量不要手動執行，讓它自動默認執行就可以了
 

5.當你正在建立一個大的新索引時（相當於直接全部寫入buffer，先不refresh，寫完再refresh），可以先關閉自動刷新，待開始使用該索引時，再把它們調回來：

PUT /my_logs/_settings
{ "refresh_interval": -1 } 

PUT /my_logs/_settings
{ "refresh_interval": "1s" } 

 

底層 lucene

簡單來說，lucene 就是一個 jar 包，里面包含了封裝好的各種建立倒排索引的算法代碼。我們用 Java 開發的時候，引入 lucene jar，然后基於 lucene 的 api 去開發就可以了。

通過 lucene，我們可以將已有的數據建立索引，lucene 會在本地磁盤上面，給我們組織索引的數據結構。

 

倒排索引

 

在搜索引擎中，每個文檔都有一個對應的文檔 ID，文檔內容被表示為一系列關鍵詞的集合。例如，文檔 1 經過分詞，提取了 20 個關鍵詞，每個關鍵詞都會記錄它在文檔中出現的次數和出現位置。

 

詳細描述一下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）時；
  
  

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

    64 GB 內存的機器是非常理想的， 但是32 GB 和16 GB 機器也是很常見的。少於8 GB 會適得其反。

    如果你要在更快的 CPUs 和更多的核心之間選擇，選擇更多的核心更好。多個內核提供的額外並發遠勝過稍微快一點點的時鍾頻率。

    如果你負擔得起 SSD，它將遠遠超出任何旋轉介質。 基於 SSD 的節點，查詢和索引性能都有提升。如果你負擔得起，SSD 是一個好的選擇。

    即使數據中心們近在咫尺，也要避免集群跨越多個數據中心。絕對要避免集群跨越大的地理距離。

    請確保運行你應用程序的 JVM 和服務器的 JVM 是完全一樣的。 在 Elasticsearch 的幾個地方，使用 Java 的本地序列化。

    通過設置gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time可以在集群重啟的時候避免過多的分片交換，這可能會讓數據恢復從數個小時縮短為幾秒鍾。

    Elasticsearch 默認被配置為使用單播發現，以防止節點無意中加入集群。只有在同一台機器上運行的節點才會自動組成集群。最好使用單播代替組播。

    不要隨意修改垃圾回收器（CMS）和各個線程池的大小。

    把你的內存的（少於）一半給 Lucene（但不要超過 32 GB！），通過ES_HEAP_SIZE 環境變量設置。

    內存交換到磁盤對服務器性能來說是致命的。如果內存交換到磁盤上，一個 100 微秒的操作可能變成 10 毫秒。 再想想那么多 10 微秒的操作時延累加起來。 不難看出 swapping 對於性能是多么可怕。

    Lucene 使用了大量的文件。同時，Elasticsearch 在節點和 HTTP 客戶端之間進行通信也使用了大量的套接字。 所有這一切都需要足夠的文件描述符。你應該增加你的文件描述符，設置一個很大的值，如 64,000。

 

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的倒排索引是什么？

面試官：想了解你對基礎概念的認知。

解答：通俗解釋一下就可以。

傳統的我們的檢索是通過文章，逐個遍歷找到對應關鍵詞的位置。

而倒排索引，是通過分詞策略，形成了詞和文章的映射關系表，這種詞典+映射表即為倒排索引。

有了倒排索引，就能實現o（1）時間復雜度的效率檢索文章了，極大的提高了檢索效率。

 

學術的解答方式：

倒排索引，相反於一篇文章包含了哪些詞，它從詞出發，記載了這個詞在哪些文檔中出現過，由兩部分組成——詞典和倒排表。

加分項：倒排索引的底層實現是基於：FST（Finite State Transducer）數據結構。

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選舉的？

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

解答：

前置前提：

1）只有候選主節點（master：true）的節點才能成為主節點。

2）最小主節點數（min_master_nodes）的目的是防止腦裂。

這個我看了各種網上分析的版本和源碼分析的書籍，雲里霧里。

核對了一下代碼，核心入口為findMaster，選擇主節點成功返回對應Master，否則返回null。選舉流程大致描述如下：

第一步：確認候選主節點數達標，elasticsearch.yml設置的值discovery.zen.minimum_master_nodes；

第二步：比較：先判定是否具備master資格，具備候選主節點資格的優先返回；若兩節點都為候選主節點，則id小的值會主節點。注意這里的id為string類型。

題外話：獲取節點id的方法。

1、GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name

2、ip        port heapPercent heapMax id  name

3、127.0.0.1 9300          39  1.9gb Hk9w Hk9wFwU

 

5、詳細描述一下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)

 

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

 

#小結

看到題目后，感覺熟悉又陌生。真正要在面試的時候講出來，需要下一番功夫深入理解。

為了求證回答的相對准確性，我翻看了源碼、官方文檔和部分有深度的博文。

Elasticsearch路還很長，別無他法，唯有死磕！

題目來源：

https://github.com/randian666/algorithm-study#搜索

https://www.cnblogs.com/luckcs/articles/7052932.html

核心參考：

1、http://www.cnblogs.com/LBSer/p/4119841.html

2、https://blog.csdn.net/njpjsoftdev/article/details/54015485

3、https://elasticsearch.cn/book/elasticsearch_definitive_guide_2.x/distrib-write.html

4、http://www.cnblogs.com/forfuture1978/archive/2010/05/19/1738806.html

5、《Elasticsearch源碼解析和優化實踐》