Elasticsearch是如何實現Master選舉的？

• Elasticsearch的選主是ZenDiscovery模組負責的，主要包含Ping（節點之間通過這個RPC來發現彼此）和Unicast（單播模組包含一個主機列表以控制哪些節點需要ping通）這兩部分；
• 對所有可以成為master的節點（node.master: true）根據nodeId字典排序，每次選舉每個節點都把自己所知道節點排一次序，然後選出第一個（第0位）節點，暫且認為它是master節點。
• 如果對某個節點的投票數達到一定的值（可以成為master節點數n/2+1）並且該節點自己也選舉自己，那這個節點就是master。否則重新選舉一直到滿足上述條件。
• 補充：master節點的職責主要包括叢集、節點和索引的管理，不負責文件級別的管理；data節點可以關閉http功能。

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

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

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

• TransportClient利用transport模組遠端連線一個elasticsearch叢集。它並不加入到叢集中，只是簡單的獲得一個或者多個初始化的transport地址，並以 輪詢 的方式與這些地址進行通訊。

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

補充：關於Lucene的Segement：

• Lucene索引是由多個段組成，段本身是一個功能齊全的倒排索引。
• 段是不可變的，允許Lucene將新的文件增量地新增到索引中，而不用從頭重建索引。
• 對於每一個搜尋請求而言，索引中的所有段都會被搜尋，並且每個段會消耗CPU的時鐘周、檔案控制代碼和記憶體。這意味著段的數量越多，搜尋效能會越低。
• 為了解決這個問題，Elasticsearch會合並小段到一個較大的段，提交新的合併段到磁碟，並刪除那些舊的小段。

詳細描述一下Elasticsearch更新和刪除文件的過程。

• 刪除和更新也都是寫操作，但是Elasticsearch中的文件是不可變的，因此不能被刪除或者改動以展示其變更；
• 磁碟上的每個段都有一個相應的.del檔案。當刪除請求傳送後，文件並沒有真的被刪除，而是在.del檔案中被標記為刪除。該文件依然能匹配查詢，但是會在結果中被過濾掉。當段合併時，在.del檔案中被標記為刪除的文件將不會被寫入新段。
• 在新的文件被建立時，Elasticsearch會為該文件指定一個版本號，當執行更新時，舊版本的文件在.del檔案中被標記為刪除，新版本的文件被索引到一個新段。舊版本的文件依然能匹配查詢，但是會在結果中被過濾掉。

詳細描述一下Elasticsearch搜尋的過程。

• 搜尋被執行成一個兩階段過程，我們稱之為 Query Then Fetch；
• 在初始查詢階段時，查詢會廣播到索引中每一個分片拷貝（主分片或者副本分片）。 每個分片在本地執行搜尋並構建一個匹配文件的大小為 from + size 的優先佇列。PS：在搜尋的時候是會查詢Filesystem Cache的，但是有部分資料還在Memory Buffer，所以搜尋是近實時的。
• 每個分片返回各自優先佇列中 所有文件的 ID 和排序值 給協調節點，它合併這些值到自己的優先佇列中來產生一個全域性排序後的結果列表。
• 接下來就是 取回階段，協調節點辨別出哪些文件需要被取回並向相關的分片提交多個 GET 請求。每個分片載入並 豐富 文件，如果有需要的話，接著返回文件給協調節點。一旦所有的文件都被取回了，協調節點返回結果給客戶端。
• 補充：Query Then Fetch的搜尋型別在文件相關性打分的時候參考的是本分片的資料，這樣在文件數量較少的時候可能不夠準確，DFS Query Then Fetch增加了一個預查詢的處理，詢問Term和Document frequency，這個評分更準確，但是效能會變差。

在Elasticsearch中，是怎麼根據一個詞找到對應的倒排索引的？

SEE：

• Lucene的索引檔案格式(1)
• Lucene的索引檔案格式(2)

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 關閉副本。

對於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使用情況做持續的監控。

Elasticsearch對於大資料量（上億量級）的聚合如何實現？

• Elasticsearch 提供的首個近似聚合是cardinality 度量。它提供一個欄位的基數，即該欄位的distinct或者unique值的數目。它是基於HLL演算法的。HLL 會先對我們的輸入作雜湊運算，然後根據雜湊運算的結果中的 bits 做概率估算從而得到基數。其特點是：可配置的精度，用來控制記憶體的使用（更精確 ＝ 更多記憶體）；小的資料集精度是非常高的；我們可以通過配置引數，來設定去重需要的固定記憶體使用量。無論數千還是數十億的唯一值，記憶體使用量只與你配置的精確度相關。

在併發情況下，Elasticsearch如果保證讀寫一致？

• 可以通過版本號使用樂觀併發控制，以確保新版本不會被舊版本覆蓋，由應用層來處理具體的衝突；
• 另外對於寫操作，一致性級別支援quorum/one/all，預設為quorum，即只有當大多數分片可用時才允許寫操作。但即使大多數可用，也可能存在因為網路等原因導致寫入副本失敗，這樣該副本被認為故障，分片將會在一個不同的節點上重建。
• 對於讀操作，可以設定replication為sync(預設)，這使得操作在主分片和副本分片都完成後才會返回；如果設定replication為async時，也可以通過設定搜尋請求引數_preference為primary來查詢主分片，確保文件是最新版本。

如何監控Elasticsearch叢集狀態？

• Marvel 讓你可以很簡單的通過 Kibana 監控 Elasticsearch。你可以實時檢視你的叢集健康狀態和效能，也可以分析過去的叢集、索引和節點指標。

介紹下你們電商搜尋的整體技術架構。

介紹一下你們的個性化搜尋方案？

SEE 基於word2vec和Elasticsearch實現個性化搜尋

是否瞭解字典樹？

• 常用字典資料結構如下所示：

• Trie的核心思想是空間換時間，利用字串的公共字首來降低查詢時間的開銷以達到提高效率的目的。它有3個基本性質：

根節點不包含字元，除根節點外每一個節點都只包含一個字元。
從根節點到某一節點，路徑上經過的字元連線起來，為該節點對應的字串。
每個節點的所有子節點包含的字元都不相同。

• 可以看到，trie樹每一層的節點數是26^i級別的。所以為了節省空間，我們還可以用動態連結串列，或者用陣列來模擬動態。而空間的花費，不會超過單詞數×單詞長度。
• 實現：對每個結點開一個字母集大小的陣列，每個結點掛一個連結串列，使用左兒子右兄弟表示法記錄這棵樹；
• 對於中文的字典樹，每個節點的子節點用一個雜湊表儲存，這樣就不用浪費太大的空間，而且查詢速度上可以保留雜湊的複雜度O(1)。

拼寫糾錯是如何實現的？

• 拼寫糾錯是基於編輯距離來實現；編輯距離是一種標準的方法，它用來表示經過插入、刪除和替換操作從一個字串轉換到另外一個字串的最小操作步數；
• 編輯距離的計算過程：比如要計算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這個滿足條件的結果。