ElasticSearch 常見問題 丈夫有淚不輕彈，只因未到傷心處。 1、說說 es 的一些調優手段。 僅索引層面調優手段： 1.1、設計階段調優 （1）根據業務增量需求，採取基於日期模板創建索引，通過 roll over API 滾動索引； （2）使用別名進行索引管理； （3）每天凌晨定時對索引 ...
ElasticSearch 常見問題
丈夫有淚不輕彈，只因未到傷心處。
1、說說 es 的一些調優手段。
僅索引層面調優手段：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、什麼是 ES 倒排索引？
通俗解釋：
傳統的我們的檢索是通過文章，逐個遍歷找到對應關鍵詞的位置。 而倒排索引，是通過分詞策略，形成了詞和文章的映射關係表，這種詞典+映射表即為倒排索引。有了倒排索引，就能實現 O（1）時間複雜度的效率檢索文章了，極大的提高了檢索效率。
學術解釋：
倒排索引，相反於一篇文章包含了哪些詞，它從詞出發，記載了這個詞在哪些文檔中出現過，由兩部分組成——詞典和倒排表。 倒排索引的底層實現是基於：FST（Finite State Transducer）數據結構。lucene 從 4+版本後開始大量使用的數據結構是 FST。FST 有兩個優點： （1）空間占用小。通過對詞典中單詞首碼和尾碼的重覆利用，壓縮了存儲空間； （2）查詢速度快。O(len(str))的查詢時間複雜度。
3、ES 索引數據多了怎麼辦？如何調優、部署？
索引數據的規劃，應在前期做好規劃，正所謂“設計先行，編碼在後”，這樣才能有效的避免突如其來的數據激增導致集群處理能力不足引發的線上客戶檢索或者其他業務受到影響。 如何調優，正如問題 1 所說。3.1 動態索引層面
基於模板+時間+rollover api 滾動創建索引。 舉例：設計階段定義：blog 索引的模板格式為：blog_index_時間戳的形式，每天遞增數據。這樣做的好處：不至於數據量激增導致單個索引數據量非常大，接近於上線 2 的32 次冪-1，索引存儲達到了 TB+甚至更大。 一旦單個索引很大，存儲等各種風險也隨之而來，所以要提前考慮+及早避免。3.2 存儲層面
冷熱數據分離存儲，熱數據（比如最近 3 天或者一周的數據），其餘為冷數據。 對於冷數據不會再寫入新數據，可以考慮定期 force_merge 加 shrink 壓縮操作，節省存儲空間和檢索效率。3.3 部署層面
一旦之前沒有規劃，這裡就屬於應急策略。 結合 ES 自身的支持動態擴展的特點，動態新增機器的方式可以緩解集群壓力，註意：如果之前主節點等規劃合理，不需要重啟集群也能完成動態新增的。4、elasticsearch 是如何實現 master 選舉的？
前置前提： （1）只有候選主節點（master：true）的節點才能成為主節點。 （2）最小主節點數（min_master_nodes）的目的是防止腦裂。 核對了一下代碼，核心入口為 findMaster，選擇主節點成功返回對應 Master，否則返回 null。選舉流程大致描述如下： 第一步：確認候選主節點數達標，elasticsearch.yml 設置的值 discovery.zen.minimum_master_nodes； 第二步：比較，先判定是否具備 master 資格，具備候選主節點資格的優先返回；若兩節點都為候選主節點，則 id 小的值會主節點。註意這裡的 id 為 string 類型。1 GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name
2 ip port heapPercent heapMax id name
5、描述一下 Elasticsearch 索引文檔的過程
這裡的索引文檔應該理解為文檔寫入 ES，創建索引的過程。 文檔寫入包含：單文檔寫入和批量 bulk 寫入，這裡只解釋一下：單文檔寫入流程。
第一步：客戶向集群某節點寫入數據，發送請求。（如果沒有指定路由/協調節點，請求的節點扮演路由節點的角色。）
第二步：節點 1 接受到請求後，使用文檔_id 來確定文檔屬於分片 0。請求會被轉到另外的節點，假定節點 3。因此分片 0 的主分片分配到節點 3 上。
第三步：節點 3 在主分片上執行寫操作，如果成功，則將請求並行轉發到節點 1和節點 2 的副本分片上，等待結果返回。所有的副本分片都報告成功，節點 3 將向協調節點（節點 1）報告成功，節點 1 向請求客戶端報告寫入成功。
如果面試官再問：第二步中的文檔獲取分片的過程？
回答：藉助路由演算法獲取，路由演算法就是根據路由和文檔 id 計算目標的分片 id 的過程。
6、描述一下 Elasticsearch 搜索的過程？
搜索拆解為“query then fetch” 兩個階段。 query 階段的目的：定位到位置，但不取數據。步驟拆解如下： （1）假設一個索引數據有 5 主+1 副本 共 10 分片，一次請求會命中（主或者副本分片中）的一個。 （2）每個分片在本地進行查詢，結果返回到本地有序的優先隊列中。 （3）第 2）步驟的結果發送到協調節點，協調節點產生一個全局的排序列表。 fetch 階段的目的：取數據。路由節點獲取所有文檔，返回給客戶端。7、ES 在部署時，對 Linux 的設置有哪些優化方法？
（1）關閉緩存 swap; （2）堆記憶體設置為：Min（節點記憶體/2, 32GB）; （3）設置最大文件句柄數； （4）線程池+隊列大小根據業務需要做調整； （5）磁碟存儲 raid 方式——存儲有條件使用 RAID10，增加單節點性能以及避免單節點存儲故障。8、lucence 內部結構是什麼？
Lucene 是有索引和搜索的兩個過程。- 索引創建：將現實世界中所有的結構化和非結構化數據提取信息，創建索引的過程。
- 搜索索引：就是得到用戶的查詢請求，搜索創建的索引，然後返回結果的過程。
9、ES 是如何實現 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 索引文檔的過程。
協調節點預設使用文檔 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 中的數據寫入到磁碟中時，才會清除掉，這個過程叫做 flush； （3）在 flush 過程中，記憶體中的緩衝將被清除，內容被寫入一個新段，段的 fsync將創建一個新的提交點，並將內容刷新到磁碟，舊的 translog 將被刪除並開始一個新的 translog。 （4）flush 觸發的時機是定時觸發（預設 30 分鐘）或者 translog 變得太大（預設為 512M）時； 補充：關於 Lucene 的 Segement： （1）Lucene 索引是由多個段組成，段本身是一個功能齊全的倒排索引。 （2）段是不可變的，允許 Lucene 將新的文檔增量地添加到索引中，而不用從頭重建索引。 （3）對於每一個搜索請求而言，索引中的所有段都會被搜索，並且每個段會消耗CPU 的時鐘周、文件句柄和記憶體。這意味著段的數量越多，搜索性能會越低。 （4）為瞭解決這個問題，Elasticsearch 會合併小段到一個較大的段，提交新的合併段到磁碟，並刪除那些舊的小段。
