Elasticsearch是如何實現(xiàn)Master選舉的？

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

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

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

客戶端在和集群連接時，如何選擇特定的節(jié)點執(zhí)行請求的？

• TransportClient利用transport模塊遠程連接一個elasticsearch集群。它并不加入到集群中，只是簡單的獲得一個或者多個初始化的transport地址，并以?輪詢?的方式與這些地址進行通信。

詳細描述一下Elasticsearch索引文檔的過程。

• 協(xié)調(diào)節(jié)點默認使用文檔ID參與計算（也支持通過routing），以便為路由提供合適的分片。

shard = hash(document_id) % (num_of_primary_shards)

• 當分片所在的節(jié)點接收到來自協(xié)調(diào)節(jié)點的請求后，會將請求寫入到Memory Buffer，然后定時（默認是每隔1秒）寫入到Filesystem Cache，這個從Momery Buffer到Filesystem Cache的過程就叫做refresh；
• 當然在某些情況下，存在Momery Buffer和Filesystem Cache的數(shù)據(jù)可能會丟失，ES是通過translog的機制來保證數(shù)據(jù)的可靠性的。其實現(xiàn)機制是接收到請求后，同時也會寫入到translog中，當Filesystem cache中的數(shù)據(jù)寫入到磁盤中時，才會清除掉，這個過程叫做flush；
• 在flush過程中，內(nèi)存中的緩沖將被清除，內(nèi)容被寫入一個新段，段的fsync將創(chuàng)建一個新的提交點，并將內(nèi)容刷新到磁盤，舊的translog將被刪除并開始一個新的translog。
• flush觸發(fā)的時機是定時觸發(fā)（默認30分鐘）或者translog變得太大（默認為512M）時；

補充：關(guān)于Lucene的Segement：

• Lucene索引是由多個段組成，段本身是一個功能齊全的倒排索引。
• 段是不可變的，允許Lucene將新的文檔增量地添加到索引中，而不用從頭重建索引。
• 對于每一個搜索請求而言，索引中的所有段都會被搜索，并且每個段會消耗CPU的時鐘周、文件句柄和內(nèi)存。這意味著段的數(shù)量越多，搜索性能會越低。
• 為了解決這個問題，Elasticsearch會合并小段到一個較大的段，提交新的合并段到磁盤，并刪除那些舊的小段。

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

• 刪除和更新也都是寫操作，但是Elasticsearch中的文檔是不可變的，因此不能被刪除或者改動以展示其變更；
• 磁盤上的每個段都有一個相應(yīng)的.del文件。當刪除請求發(fā)送后，文檔并沒有真的被刪除，而是在.del文件中被標記為刪除。該文檔依然能匹配查詢，但是會在結(jié)果中被過濾掉。當段合并時，在.del文件中被標記為刪除的文檔將不會被寫入新段。
• 在新的文檔被創(chuàng)建時，Elasticsearch會為該文檔指定一個版本號，當執(zhí)行更新時，舊版本的文檔在.del文件中被標記為刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結(jié)果中被過濾掉。

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

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

在Elasticsearch中，是怎么根據(jù)一個詞找到對應(yīng)的倒排索引的？

SEE：

• Lucene的索引文件格式(1)
• Lucene的索引文件格式(2)

Elasticsearch在部署時，對Linux的設(shè)置有哪些優(yōu)化方法？

• 64 GB 內(nèi)存的機器是非常理想的， 但是32 GB 和16 GB 機器也是很常見的。少于8 GB 會適得其反。
• 如果你要在更快的 CPUs 和更多的核心之間選擇，選擇更多的核心更好。多個內(nèi)核提供的額外并發(fā)遠勝過稍微快一點點的時鐘頻率。
• 如果你負擔(dān)得起 SSD，它將遠遠超出任何旋轉(zhuǎn)介質(zhì)。 基于 SSD 的節(jié)點，查詢和索引性能都有提升。如果你負擔(dān)得起，SSD 是一個好的選擇。
• 即使數(shù)據(jù)中心們近在咫尺，也要避免集群跨越多個數(shù)據(jù)中心。絕對要避免集群跨越大的地理距離。
• 請確保運行你應(yīng)用程序的 JVM 和服務(wù)器的 JVM 是完全一樣的。 在 Elasticsearch 的幾個地方，使用 Java 的本地序列化。
• 通過設(shè)置gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time可以在集群重啟的時候避免過多的分片交換，這可能會讓數(shù)據(jù)恢復(fù)從數(shù)個小時縮短為幾秒鐘。
• Elasticsearch 默認被配置為使用單播發(fā)現(xiàn)，以防止節(jié)點無意中加入集群。只有在同一臺機器上運行的節(jié)點才會自動組成集群。最好使用單播代替組播。
• 不要隨意修改垃圾回收器（CMS）和各個線程池的大小。
• 把你的內(nèi)存的（少于）一半給 Lucene（但不要超過 32 GB！），通過ES_HEAP_SIZE 環(huán)境變量設(shè)置。
• 內(nèi)存交換到磁盤對服務(wù)器性能來說是致命的。如果內(nèi)存交換到磁盤上，一個 100 微秒的操作可能變成 10 毫秒。 再想想那么多 10 微秒的操作時延累加起來。 不難看出 swapping 對于性能是多么可怕。
• Lucene 使用了大量的文件。同時，Elasticsearch 在節(jié)點和 HTTP 客戶端之間進行通信也使用了大量的套接字。 所有這一切都需要足夠的文件描述符。你應(yīng)該增加你的文件描述符，設(shè)置一個很大的值，如 64,000。

補充：索引階段性能提升方法

• 使用批量請求并調(diào)整其大小：每次批量數(shù)據(jù) 5–15 MB 大是個不錯的起始點。
• 存儲：使用 SSD
• 段和合并：Elasticsearch 默認值是 20 MB/s，對機械磁盤應(yīng)該是個不錯的設(shè)置。如果你用的是 SSD，可以考慮提高到 100–200 MB/s。如果你在做批量導(dǎo)入，完全不在意搜索，你可以徹底關(guān)掉合并限流。另外還可以增加 index.translog.flush_threshold_size 設(shè)置，從默認的 512 MB 到更大一些的值，比如 1 GB，這可以在一次清空觸發(fā)的時候在事務(wù)日志里積累出更大的段。
• 如果你的搜索結(jié)果不需要近實時的準確度，考慮把每個索引的index.refresh_interval 改到30s。
• 如果你在做大批量導(dǎo)入，考慮通過設(shè)置index.number_of_replicas: 0 關(guān)閉副本。

對于GC方面，在使用Elasticsearch時要注意什么？

• SEE：https://elasticsearch.cn/article/32
• 倒排詞典的索引需要常駐內(nèi)存，無法GC，需要監(jiān)控data node上segment memory增長趨勢。
• 各類緩存，field cache, filter cache, indexing cache, bulk queue等等，要設(shè)置合理的大小，并且要應(yīng)該根據(jù)最壞的情況來看heap是否夠用，也就是各類緩存全部占滿的時候，還有heap空間可以分配給其他任務(wù)嗎？避免采用clear cache等“自欺欺人”的方式來釋放內(nèi)存。
• 避免返回大量結(jié)果集的搜索與聚合。確實需要大量拉取數(shù)據(jù)的場景，可以采用scan & scroll api來實現(xiàn)。
• cluster stats駐留內(nèi)存并無法水平擴展，超大規(guī)模集群可以考慮分拆成多個集群通過tribe node連接。
• 想知道heap夠不夠，必須結(jié)合實際應(yīng)用場景，并對集群的heap使用情況做持續(xù)的監(jiān)控。

Elasticsearch對于大數(shù)據(jù)量（上億量級）的聚合如何實現(xiàn)？

• Elasticsearch 提供的首個近似聚合是cardinality 度量。它提供一個字段的基數(shù)，即該字段的distinct或者unique值的數(shù)目。它是基于HLL算法的。HLL 會先對我們的輸入作哈希運算，然后根據(jù)哈希運算的結(jié)果中的 bits 做概率估算從而得到基數(shù)。其特點是：可配置的精度，用來控制內(nèi)存的使用（更精確 ＝ 更多內(nèi)存）；小的數(shù)據(jù)集精度是非常高的；我們可以通過配置參數(shù)，來設(shè)置去重需要的固定內(nèi)存使用量。無論數(shù)千還是數(shù)十億的唯一值，內(nèi)存使用量只與你配置的精確度相關(guān)。

在并發(fā)情況下，Elasticsearch如果保證讀寫一致？

• 可以通過版本號使用樂觀并發(fā)控制，以確保新版本不會被舊版本覆蓋，由應(yīng)用層來處理具體的沖突；
• 另外對于寫操作，一致性級別支持quorum/one/all，默認為quorum，即只有當大多數(shù)分片可用時才允許寫操作。但即使大多數(shù)可用，也可能存在因為網(wǎng)絡(luò)等原因?qū)е聦懭敫北臼?#xff0c;這樣該副本被認為故障，分片將會在一個不同的節(jié)點上重建。
• 對于讀操作，可以設(shè)置replication為sync(默認)，這使得操作在主分片和副本分片都完成后才會返回；如果設(shè)置replication為async時，也可以通過設(shè)置搜索請求參數(shù)_preference為primary來查詢主分片，確保文檔是最新版本。

如何監(jiān)控Elasticsearch集群狀態(tài)？

• Marvel 讓你可以很簡單的通過 Kibana 監(jiān)控 Elasticsearch。你可以實時查看你的集群健康狀態(tài)和性能，也可以分析過去的集群、索引和節(jié)點指標。

介紹下你們電商搜索的整體技術(shù)架構(gòu)。

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

SEE?基于word2vec和Elasticsearch實現(xiàn)個性化搜索

是否了解字典樹？

• 常用字典數(shù)據(jù)結(jié)構(gòu)如下所示：

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

根節(jié)點不包含字符，除根節(jié)點外每一個節(jié)點都只包含一個字符。 從根節(jié)點到某一節(jié)點，路徑上經(jīng)過的字符連接起來，為該節(jié)點對應(yīng)的字符串。 每個節(jié)點的所有子節(jié)點包含的字符都不相同。

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

拼寫糾錯是如何實現(xiàn)的？

• 拼寫糾錯是基于編輯距離來實現(xiàn)；編輯距離是一種標準的方法，它用來表示經(jīng)過插入、刪除和替換操作從一個字符串轉(zhuǎn)換到另外一個字符串的最小操作步數(shù)；
• 編輯距離的計算過程：比如要計算batyu和beauty的編輯距離，先創(chuàng)建一個7×8的表（batyu長度為5，coffee長度為6，各加2），接著，在如下位置填入黑色數(shù)字。其他格的計算過程是取以下三個值的最小值：

如果最上方的字符等于最左方的字符，則為左上方的數(shù)字。否則為左上方的數(shù)字+1。（對于3,3來說為0） 左方數(shù)字+1（對于3,3格來說為2） 上方數(shù)字+1（對于3,3格來說為2）

最終取右下角的值即為編輯距離的值3。

• 對于拼寫糾錯，我們考慮構(gòu)造一個度量空間（Metric Space），該空間內(nèi)任何關(guān)系滿足以下三條基本條件：

d(x,y) = 0 -- 假如x與y的距離為0，則x=y d(x,y) = d(y,x) -- x到y(tǒng)的距離等同于y到x的距離 d(x,y) + d(y,z) >= d(x,z) -- 三角不等式

• 根據(jù)三角不等式，則滿足與query距離在n范圍內(nèi)的另一個字符轉(zhuǎn)B，其與A的距離最大為d+n，最小為d-n。
• BK樹的構(gòu)造就過程如下：每個節(jié)點有任意個子節(jié)點，每條邊有個值表示編輯距離。所有子節(jié)點到父節(jié)點的邊上標注n表示編輯距離恰好為n。比如，我們有棵樹父節(jié)點是”book”和兩個子節(jié)點”cake”和”books”，”book”到”books”的邊標號1，”book”到”cake”的邊上標號4。從字典里構(gòu)造好樹后，無論何時你想插入新單詞時，計算該單詞與根節(jié)點的編輯距離，并且查找數(shù)值為d(neweord, root)的邊。遞歸得與各子節(jié)點進行比較，直到?jīng)]有子節(jié)點，你就可以創(chuàng)建新的子節(jié)點并將新單詞保存在那。比如，插入”boo”到剛才上述例子的樹中，我們先檢查根節(jié)點，查找d(“book”, “boo”) = 1的邊，然后檢查標號為1的邊的子節(jié)點，得到單詞”books”。我們再計算距離d(“books”, “boo”)=2，則將新單詞插在”books”之后，邊標號為2。
• 查詢相似詞如下：計算單詞與根節(jié)點的編輯距離d，然后遞歸查找每個子節(jié)點標號為d-n到d+n（包含）的邊。假如被檢查的節(jié)點與搜索單詞的距離d小于n，則返回該節(jié)點并繼續(xù)查詢。比如輸入cape且最大容忍距離為1，則先計算和根的編輯距離d(“book”, “cape”)=4，然后接著找和根節(jié)點之間編輯距離為3到5的，這個就找到了cake這個節(jié)點，計算d(“cake”, “cape”)=1，滿足條件所以返回cake，然后再找和cake節(jié)點編輯距離是0到2的，分別找到cape和cart節(jié)點，這樣就得到cape這個滿足條件的結(jié)果。

總結(jié)

以上是生活随笔為你收集整理的ElasticSearch 知识点整理（深入）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。