文章來源于阿裡雲 MVP銘毅。
git上發現了網友總結的Elasticsearch BAT大廠面試題。隻有題目，部分有答案，但不全。 正好抽出一些時間一起梳理一下。
既然是面試題，每個人都會有自己的結合業務場景的答案，沒有非常标準的答案。
歡迎大家留言拍磚指正。
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的方法。
5、較長的描述一下Elasticsearch索引文檔的過程？
面試官：想了解ES的底層原理，不再隻關注業務層面了。
這裡的索引文檔應該了解為文檔寫入ES，建立索引的過程。
文檔寫入包含：單文檔寫入和批量bulk寫入，這裡隻解釋一下：單文檔寫入流程。
記住官方文檔中的這個圖。
第一步：客戶寫叢集某節點寫入資料，發送請求。（如果沒有指定路由/協調節點，請求的節點扮演路由節點的角色。）
第二步：節點1接受到請求後，使用文檔_id來确定文檔屬于分片0。請求會被轉到另外的節點，假定節點3。是以分片0的主分片配置設定到節點3上。
第三步：節點3在主分片上執行寫操作，如果成功，則将請求并行轉發到節點1和節點2的副本分片上，等待結果傳回。所有的副本分片都報告成功，節點3将向協調節點（節點1）報告成功，節點1向請求用戶端報告寫入成功。
如果面試官再問：第二步中的文檔擷取分片的過程？
回答：借助路由算法擷取，路由算法就是根據路由和文檔id計算目标的分片id的過程。
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.html2、
https://blog.csdn.net/njpjsoftdev/article/details/540154853、
https://elasticsearch.cn/book/elasticsearch_definitive_guide_2.x/distrib-write.html4、
http://www.cnblogs.com/forfuture1978/archive/2010/05/19/1738806.html5、《Elasticsearch源碼解析和優化實踐》
文章轉自CSDN.