1.爲什麼要使用Elasticsearch?
因爲在我們商城中的數據，將來會非常多，所以採用以往的模糊查詢，模糊查詢前置配置，會放棄索引，導致商品查詢是全表掃面，在百萬級別的數據庫中，效率非常低下，而我們使用ES做一個全文索引，我們將經常查詢的商品的某些字段，比如說商品名，描述、價格還有id這些字段我們放入我們索引庫裏，可以提高查詢速度。
2.Elasticsearch是如何實現Master選舉的？
- Elasticsearch的選主是ZenDiscovery模塊負責的，主要包含Ping（節點之間通過這個RPC來發現彼此）和Unicast（單播模塊包含一個主機列表以控制哪些節點需要ping通）這兩部分；
- 對所有可以成爲master的節點（node.master: true）根據nodeId字典排序，每次選舉每個節點都把自己所知道節點排一次序，然後選出第一個（第0位）節點，暫且認爲它是master節點。
- 如果對某個節點的投票數達到一定的值（可以成爲master節點數n/2+1）並且該節點自己也選舉自己，那這個節點就是master。否則重新選舉一直到滿足上述條件。
- 補充：master節點的職責主要包括集羣、節點和索引的管理，不負責文檔級別的管理；data節點可以關閉http功能。
3.Elasticsearch中的節點（比如共20個），其中的10個選了一個master，另外10個選了另一個master，怎麼辦？
- 當集羣master候選數量不小於3個時，可以通過設置最少投票通過數量（discovery.zen.minimum_master_nodes）超過所有候選節點一半以上來解決腦裂問題；
- 當候選數量爲兩個時，只能修改爲唯一的一個master候選，其他作爲data節點，避免腦裂問題。
4.詳細描述一下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）時；
5.詳細描述一下Elasticsearch更新和刪除文檔的過程
- 刪除和更新也都是寫操作，但是Elasticsearch中的文檔是不可變的，因此不能被刪除或者改動以展示其變更；
- 磁盤上的每個段都有一個相應的.del文件。當刪除請求發送後，文檔並沒有真的被刪除，而是在.del文件中被標記爲刪除。該文檔依然能匹配查詢，但是會在結果中被過濾掉。當段合併時，在.del文件中被標記爲刪除的文檔將不會被寫入新段。
- 在新的文檔被創建時，Elasticsearch會爲該文檔指定一個版本號，當執行更新時，舊版本的文檔在.del文件中被標記爲刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結果中被過濾掉。
6.詳細描述一下Elasticsearch搜索的過程
- 搜索被執行成一個兩階段過程，我們稱之爲 Query Then Fetch；
- 在初始查詢階段時，查詢會廣播到索引中每一個分片拷貝（主分片或者副本分片）。 每個分片在本地執行搜索並構建一個匹配文檔的大小爲 from + size 的優先隊列。PS：在搜索的時候是會查詢Filesystem Cache的，但是有部分數據還在Memory Buffer，所以搜索是近實時的。
- 每個分片返回各自優先隊列中 所有文檔的 ID 和排序值 給協調節點，它合併這些值到自己的優先隊列中來產生一個全局排序後的結果列表。
- 接下來就是 取回階段，協調節點辨別出哪些文檔需要被取回並向相關的分片提交多個 GET 請求。每個分片加載並 豐富 文檔，如果有需要的話，接着返回文檔給協調節點。一旦所有的文檔都被取回了，協調節點返回結果給客戶端。
- 補充：Query Then Fetch的搜索類型在文檔相關性打分的時候參考的是本分片的數據，這樣在文檔數量較少的時候可能不夠準確，DFS Query Then Fetch增加了一個預查詢的處理，詢問Term和Document frequency，這個評分更準確，但是性能會變差。
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。
補充：索引階段性能提升方法
-
使用批量請求並調整其大小：每次批量數據 5–15 MB 大是個不錯的起始點。
-
存儲：使用 SSD
-
段和合並：Elasticsearch 默認值是 20 MB/s，對機械磁盤應該是個不錯的設置。如果你用的是 SSD，可以考慮提高到 100–200 MB/s。如果你在做批量導入，完全不在意搜索，你可以徹底關掉合併限流。另外還可以增加 index.translog.flush_threshold_size 設置，從默認的 512 MB 到更大一些的值，比如 1 GB，這可以在一次清空觸發的時候在事務日誌裏積累出更大的段。
-
如果你的搜索結果不需要近實時的準確度，考慮把每個索引的index.refresh_interval 改到30s。
-
如果你在做大批量導入，考慮通過設置index.number_of_replicas: 0 關閉副本。
8.對於GC方面，在使用Elasticsearch時要注意什麼？
- SEE：https://elasticsearch.cn/article/32
- 倒排詞典的索引需要常駐內存，無法GC，需要監控data node上segment memory增長趨勢。
- 各類緩存，field cache, filter cache, indexing cache, bulk queue等等，要設置合理的大小，並且要應該根據最壞的情況來看heap是否夠用，也就是各類緩存全部佔滿的時候，還有heap空間可以分配給其他任務嗎？避免採用clear cache等“自欺欺人”的方式來釋放內存。
- 避免返回大量結果集的搜索與聚合。確實需要大量拉取數據的場景，可以採用scan & scroll api來實現。
- cluster stats駐留內存並無法水平擴展，超大規模集羣可以考慮分拆成多個集羣通過tribe node連接。
- 想知道heap夠不夠，必須結合實際應用場景，並對集羣的heap使用情況做持續的監控。
9.Elasticsearch對於大數據量（上億量級）的聚合如何實現？
Elasticsearch 提供的首個近似聚合是cardinality 度量。它提供一個字段的基數，即該字段的distinct或者unique值的數目。它是基於HLL算法的。HLL 會先對我們的輸入作哈希運算，然後根據哈希運算的結果中的 bits 做概率估算從而得到基數。其特點是：可配置的精度，用來控制內存的使用（更精確 ＝ 更多內存）；小的數據集精度是非常高的；我們可以通過配置參數，來設置去重需要的固定內存使用量。無論數千還是數十億的唯一值，內存使用量只與你配置的精確度相關 .
10.在併發情況下，Elasticsearch如果保證讀寫一致？
- 可以通過版本號使用樂觀併發控制，以確保新版本不會被舊版本覆蓋，由應用層來處理具體的衝突；
- 另外對於寫操作，一致性級別支持quorum/one/all，默認爲quorum，即只有當大多數分片可用時才允許寫操作。但即使大多數可用，也可能存在因爲網絡等原因導致寫入副本失敗，這樣該副本被認爲故障，分片將會在一個不同的節點上重建。
- 對於讀操作，可以設置replication爲sync(默認)，這使得操作在主分片和副本分片都完成後纔會返回；如果設置replication爲async時，也可以通過設置搜索請求參數_preference爲primary來查詢主分片，確保文檔是最新版本。
11.如何監控Elasticsearch集羣狀態？
Marvel 讓你可以很簡單的通過 Kibana 監控 Elasticsearch。你可以實時查看你的集羣健康狀態和性能，也可以分析過去的集羣、索引和節點指標
12.是否瞭解字典樹？
- 常用字典數據結構如下所示：
- Trie的核心思想是空間換時間，利用字符串的公共前綴來降低查詢時間的開銷以達到提高效率的目的。它有3個基本性質：
根節點不包含字符，除根節點外每一個節點都只包含一個字符。
從根節點到某一節點，路徑上經過的字符連接起來，爲該節點對應的字符串。
每個節點的所有子節點包含的字符都不相同。
- 可以看到，trie樹每一層的節點數是26^i級別的。所以爲了節省空間，我們還可以用動態鏈表，或者用數組來模擬動態。而空間的花費，不會超過單詞數×單詞長度。
- 實現：對每個結點開一個字母集大小的數組，每個結點掛一個鏈表，使用左兒子右兄弟表示法記錄這棵樹；
- 對於中文的字典樹，每個節點的子節點用一個哈希表存儲，這樣就不用浪費太大的空間，而且查詢速度上可以保留哈希的複雜度O(1)。
13.拼寫糾錯是如何實現的？
- 拼寫糾錯是基於編輯距離來實現；編輯距離是一種標準的方法，它用來表示經過插入、刪除和替換操作從一個字符串轉換到另外一個字符串的最小操作步數；
- 編輯距離的計算過程：比如要計算batyu和beauty的編輯距離，先創建一個7×8的表（batyu長度爲5，coffee長度爲6，各加2），接着，在如下位置填入黑色數字。其他格的計算過程是取以下三個值的最小值：
如果最上方的字符等於最左方的字符，則爲左上方的數字。否則爲左上方的數字+1。（對於3,3來說爲0）
左方數字+1（對於3,3格來說爲2）
上方數字+1（對於3,3格來說爲2）
最終取右下角的值即爲編輯距離的值3。
- 對於拼寫糾錯，我們考慮構造一個度量空間（Metric Space），該空間內任何關係滿足以下三條基本條件：
d(x,y) = 0 -- 假如x與y的距離爲0，則x=y
d(x,y) = d(y,x) -- x到y的距離等同於y到x的距離
d(x,y) + d(y,z) >= d(x,z) -- 三角不等式
- 根據三角不等式，則滿足與query距離在n範圍內的另一個字符轉B，其與A的距離最大爲d+n，最小爲d-n。
- BK樹的構造就過程如下：每個節點有任意個子節點，每條邊有個值表示編輯距離。所有子節點到父節點的邊上標註n表示編輯距離恰好爲n。比如，我們有棵樹父節點是”book”和兩個子節點”cake”和”books”，”book”到”books”的邊標號1，”book”到”cake”的邊上標號4。從字典裏構造好樹後，無論何時你想插入新單詞時，計算該單詞與根節點的編輯距離，並且查找數值爲d(neweord, root)的邊。遞歸得與各子節點進行比較，直到沒有子節點，你就可以創建新的子節點並將新單詞保存在那。比如，插入”boo”到剛纔上述例子的樹中，我們先檢查根節點，查找d(“book”, “boo”) = 1的邊，然後檢查標號爲1的邊的子節點，得到單詞”books”。我們再計算距離d(“books”, “boo”)=2，則將新單詞插在”books”之後，邊標號爲2。
- 查詢相似詞如下：計算單詞與根節點的編輯距離d，然後遞歸查找每個子節點標號爲d-n到d+n（包含）的邊。假如被檢查的節點與搜索單詞的距離d小於n，則返回該節點並繼續查詢。比如輸入cape且最大容忍距離爲1，則先計算和根的編輯距離d(“book”, “cape”)=4，然後接着找和根節點之間編輯距離爲3到5的，這個就找到了cake這個節點，計算d(“cake”, “cape”)=1，滿足條件所以返回cake，然後再找和cake節點編輯距離是0到2的，分別找到cape和cart節點，這樣就得到cape這個滿足條件的結果。
14.ElasticSearch中的集羣、節點、索引、文檔、類型是什麼？
- 羣集是一個或多個節點（服務器）的集合，它們共同保存您的整個數據，並提供跨所有節點的聯合索引和搜索功能。羣集由唯一名稱標識，默認情況下爲“elasticsearch”。此名稱很重要，因爲如果節點設置爲按名稱加入羣集，則該節點只能是羣集的一部分。
- 節點是屬於集羣一部分的單個服務器。它存儲數據並參與羣集索引和搜索功能。
- 索引就像關係數據庫中的“數據庫”。它有一個定義多種類型的映射。索引是邏輯名稱空間，映射到一個或多個主分片，並且可以有零個或多個副本分片。 MySQL =>數據庫 ElasticSearch =>索引
- 文檔類似於關係數據庫中的一行。不同之處在於索引中的每個文檔可以具有不同的結構（字段），但是對於通用字段應該具有相同的數據類型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有屬性的文檔
- 類型是索引的邏輯類別/分區，其語義完全取決於用戶。
15.ElasticSearch中的分片是什麼?
在大多數環境中，每個節點都在單獨的盒子或虛擬機上運行。
- 索引 - 在Elasticsearch中，索引是文檔的集合。
- 分片 -因爲Elasticsearch是一個分佈式搜索引擎，所以索引通常被分割成分佈在多個節點上的被稱爲分片的元素。
