es的演算法

㈠ 求工程進度中ES、EF、LS、LF、TT、FT的計算方法，通俗易懂些，呵呵，謝謝

先解釋一下這幾個的意思

ES：最早開始
EF：最早結束
LS：最遲開始

LF：最遲完成
DU：活動歷時
FT：總時差

然後說一下他們之間的換算

EF（最早結束）=ES（最早開始）+DU（活動歷時）
LF（最遲完成）=LS（最遲開始）+DU（活動歷時）
FT（總時差）=LF（最遲完成）-EF（最早結束）

㈡ ES集群原理與搭建

查看集群健康狀況：URL+ /GET _cat/health

Cluster

代表一個集群，集群中有多個節點，其中有一個為主節點，這個主節點是可以通過選舉產生的，主從節點是對於集群內部來說的。es的一個概念就是去中心化，字面上理解就是無中心節點，這是對於集群外部來說的，因為從外部來看es集群，在邏輯上是個整體，你與任何一個節點的通信和與整個es集群通信是等價的。

Shards

代表索引分片，es可以把一個完整的索引分成多個分片，這樣的好處是可以把一個大的索引拆分成多個，分布到不同的節點上。構成分布式搜索。分片的數量只能在索引創建前指定，並且索引創建後不能更改。

replicas

代表索引副本，es可以設置多個索引的副本，副本的作用一是提高系統的容錯性，當某個節點某個分片損壞或丟失時可以從副本中恢復。二是提高es的查詢效率，es會自動對搜索請求進行負載均衡。

Recovery

代表數據恢復或叫數據重新分布，es在有節點加入或退出時會根據機器的負載對索引分片進行重新分配，掛掉的節點重新啟動時也會進行數據恢復。

（2）、ES為什麼要實現集群

在單台ES伺服器節點上，隨著業務量的發展索引文件慢慢增多，會影響到效率和內存存儲問題等。

我們可以採用ES集群，將單個索引的分片到多個不同分布式物理機器上存儲，從而可以實現高可用、容錯性等。

ES集群中索引可能由多個分片構成，並且每個分片可以擁有多個副本。通過將一個單獨的索引分為多個分片，我們可以處理不能在一個單一的伺服器上面運行的大型索引，簡單的說就是索引的大小過大，導致效率問題。不能運行的原因可能是內存也可能是存儲。由於每個分片可以有多個副本，通過將副本分配到多個伺服器，可以提高查詢的負載能力。

（3）、ES是如何解決高並發

ES是一個分布式全文檢索框架，隱藏了復雜的處理機制，內部使用 分片機制、集群發現、分片負載均衡請求路由。

Shards 分片:代表索引分片，es可以把一個完整的索引分成多個分片，這樣的好處是可以把一個大的索引拆分成多個，分布到不同的節點上。構成分布式搜索。分片的數量只能在索引創建前指定，並且索引創建後不能更改。

Replicas分片:代表索引副本，es可以設置多個索引的副本，副本的作用一是提高系統的容錯性，當某個節點某個分片損壞或丟失時可以從副本中恢復。二是提高es的查詢效率，es會自動對搜索請求進行負載均衡。

1、每個索引會被分成多個分片shards進行存儲，默認創建索引是分配5個分片進行存儲。每個分片都會分布式部署在多個不同的節點上進行部署，該分片成為primary shards。

注意：索引的主分片primary shards定義好後，後面不能做修改。

2、為了實現高可用數據的高可用，主分片可以有對應的備分片replics shards，replic shards分片承載了負責容錯、以及請求的負載均衡。

注意: 每一個主分片為了實現高可用，都會有自己對應的備分片，主分片對應的備分片不能存放同一台伺服器上。主分片primary shards可以和其他replics shards存放在同一個node節點上。

3、documnet routing（數據路由）

當客戶端發起創建document的時候，es需要確定這個document放在該index哪個shard上。這個過程就是數據路由。

路由演算法：shard = hash(routing) % number_of_primary_shards

如果number_of_primary_shards在查詢的時候取余發生的變化，無法獲取到該數據

注意：索引的主分片數量定義好後，不能被修改

高可用視圖分析（下圖所示：上面的圖，如果節點1與節點2宕機了，es集群數據就不完整了。下面圖，如果節點1與節點2宕機了，es集群數據還是完整的）

（1）、伺服器環境

准備三台伺服器集群

| 伺服器名稱 | IP地址 |
| node-1 | 192.168.212.182 |
| node-2 | 192.168.212.183 |
| node-3 | 192.168.212.184 |

（2）、關閉防火牆

（3）、**** http://192.168.212.185:9200/_cat/nodes?pretty

*號表示為master節點

注意：

注意克隆data文件會導致數據不同步

報該錯誤解決辦法 ：

failed to send join request to master

因為克隆導致data文件也克隆呢，直接清除每台伺服器data文件。

㈢ 工程進度中ES、EF、LS、LF、TT、FT的計算方法是什麼

先解釋一下這幾個的意思 ES：最早開始 EF：最早結束 LS：最遲開始 LF：最遲完成 DU：活動歷時 FT：總時差 然後說一下他們之間的換算 EF（最早結束）=ES（最早開始）+DU（活動歷時） LF（最遲完成）=LS（最遲開始）+DU（活動歷時） FT（總時差）=LF（最遲完成）-EF（最早結束）

㈣ ET LT ES EF LS LF TF FF 8個時間參數怎麼算

ES、EF：

採用正向計算（從項目開始的活動逐項計算到項目結束）

ES=Latest EF(所有緊前活動項的EF）

LS、LF：

採用逆項計算（從項目結束的活動逐項計算到項目開始）

LF=Earliest (所有緊後活動項的LS）

總時差：Float=LF-EF=LS-ES

計算方法

(1)以終點節點為完成節點的工作，其總時差應等於計劃工期與本工作最早完成時間之差。

(2)其他工作的總時差等於其緊後工作的總時差加本工作與該緊後工作之間的時間間隔所得之和的最小值。

總時差。雙代號時標網路圖總時差，教材中的計算公式=緊後工作的總時差+本工作與該緊後工作之間的時間間隔所得之和的最小值。

以上內容參考：網路-總時差

㈤ ES選舉-類Bully演算法

bully演算法是一個分布式系統中動態選擇master節點的演算法，進程號最大的非失效的節點將被選為master。
演算法用三種消息類型：

當一個進程P從失敗中恢復，或者接收到主節點失效信息，進程P將做以下事情：

我看的源碼是5.6版本的。因此以下的解釋都是依據5.6的源碼來說的。
當master節點失效之後，各個節點find master的過程如下：
1）每個節點會ping配置文件中discovery.zen.ping.unicast.hosts的IP，找到所有存活的節點並過濾
2）找到非本身的active master

3）找到所有的可成為master的節點集合masterCandidates ，包含自己

4）如果activeMasters 為空，也就是說不存在活著的master節點，同時當前活著的節點滿足配置中discovery.zen.minimum_master_nodes的數量，那麼就從masterCandidates 挑出ID最小的節點，讓其成為master節點。如果activeMasters 不為空，則從中選擇最小的ID成為Master節點即可。

electMaster.electMaster方法和electMaster.tieBreakActiveMasters方法則都是從集合中選取最小節點的ID：

如果當前不存在active master，那麼activeMasters 一定為空，則從masterCandidates 從選出id最小的節點即可。
如果當前存在active master，且當前節點不是active maste，那麼從activeMasters 中選出id最小的節點。
如果當前存在active master，且當前節點是active maste，那麼activeMasters 為空，從masterCandidates 中選出id最小的節點即自己。

在我的感覺中，當前active master的個數要麼為空，要麼為1，這邊不知道為什麼要用一個鏈表。。。為了防止腦裂情況出現嗎？？

㈥ es深入搜索之全文檢索

  我們之前介紹過結構化搜索的簡單使用，接下來，我們來看怎樣在全文欄位中搜索最相關的文檔。

  全文搜索包括兩個最重要的方面：

  1. 查詢與結果的相關性，並根據相關性對結果進行排名。
  2. 分析，將數據轉化為有區別的、規范化的的過程。

  所有的查詢都或多或少的會進行相關度計算，但不是所有的查詢都會有分析階段，文本查詢可以分為兩個部分：
  1. 基於詞項的查詢，如 term 或 fuzzy 這樣的查詢是沒有分析階段的。他們對單個詞項進行操作。
  2. 基於全文的查詢，比如match， 它們會先了解欄位映射的信息，判斷欄位是否被分詞，是否是日期還是數字等， 再根據映射信息，構建要查詢的詞項列表，根據列表進行查詢。

  匹配查詢 match 是個核心查詢。無論需要查詢什麼欄位， match 查詢都應該會是首選的查詢方式。使用方式如下：

es執行上列步驟的過程如下：

  如果一次只能搜索一個詞語，那麼全文搜索會不太靈活，幸運的是 match 也支持多詞查詢 。

以上查詢其實先後執行了兩次 term 查詢，使用 bool 進行包含，然後將結果進行合並返回。

  以上查詢其實會導致出現不相關的結果，我們只想搜索包含words1 和 words2 的文檔，而不是 or 的結果。match 查詢還可以接受 operator 操作符作為輸入參數，默認情況下該操作符是 or 。

這種操作還是有些不妥，在 and 和 or 中間選擇太過絕對，如果用戶給出了5個詞項，我們想只要滿足其中4 個 就表示匹配，match 也提供了 minimum_should_match 參數，他是一個最小匹配參數，我們可以控制滿足的詞項超過改值則表示匹配，最好是使用百分比，因為你也不知道用戶提供了多少個詞項。該參數的設置非常靈活，完整的信息參考文檔，請看 https://www.elastic.co/guide/en/elasticsearch/reference/5.6/query-dsl-minimum-should-match.html#query-dsl-minimum-should-match

如果我們使用 bool 查詢黑色、大屏、手機，其中should 語句匹配得越多表示文檔的相關度越高，但是我們想要手機所佔的權重比較大，內容包括手機的文檔排名靠前，可以使用 boost 設置相對權重，注意是相對權重，默認是1。

在說相關度被破壞的原因之前，我們先看看es對於相關度是如何計算的

es 的相似度演算法被定義為檢索詞頻率/反向文檔頻率， TF/IDF ，包括以下內容：

有時，我們索引了一些文檔，然後檢索發現有些相關度較低的返回排名靠前？

  出現上述原因的情況是因為es由於性能原因，不會計算所有索引該文檔的節點的IDF,比如我們索引了10個文檔， 其中6個文檔中包含 foo ，而由於es是分布式的，一個索引會被分為多個分片，有可能分片一包含的5 個文檔，有 4 個包含foo, 而另外一個在分片二中，所以會導致結果有差異。

  在實際應用中，不會出現該問題，因為本局和全局的IDF差異會隨著文檔數量的增加逐漸降低。如果想要自己處理該問題，可以在搜索請求之後增加 ?search_type=dfs_query_then_fetch ,他會使得es先計算各個分片的 IDF, 然後在求出全局的 IDF, 生產環境中不要使用。因為只要有足夠的數據就可以使得差異減少。

㈦ ES原理之選主流程

分布式系統的集群方式大致可以分為主從模式（Master-Slave）和無主模式。

常用的選舉演算法有比較簡單的Bully演算法和復雜而強大的Paxos演算法。

每個節點有一個唯一ID，然後對集群中所有的節點ID進行排序，選取其中最小的ID所屬的節點作為Master。
Bully演算法的問題： 假設當前Master因為負載過重而假死，然後ID第二大的被選舉為新的Master，這時舊的Master恢復然後又被選舉為Master然後又會因為負載過重而假死......

Paxos實現起來非常復雜,但非常強大，尤其在什麼時機,以及如何進行選舉方面的靈活性比簡單的Bully演算法有很大的優勢，因為在現實生活中，存在比網路鏈接異常更多的故障模式。
ES使用的是Bully演算法，並對其做了一些優化：

㈧ es源碼筆記-7.x 選主流程

Discovery模塊負責發現集群中的節點，以及選擇主節點。ES支持多種不同Discovery類型選擇，內置的實現有兩種：Zen Discovery和Coordinator，其他的包括公有雲平台亞馬遜的EC2、谷歌的GCE等。

它假定所有節點都有一個唯一的ID，使用該ID對節點進行排序。任何時候的當前Leader都是參與集群的最高ID節點。該演算法的優點是易於實現。但是，當擁有最大ID的節點處於不穩定狀態的場景下會有問題。例如，Master負載過重而假死，集群擁有第二大ID的節點被選為新主，這時原來的Master恢復，再次被選為新主，然後又假死
ES 通過推遲選舉，直到當前的 Master 失效來解決上述問題，只要當前主節點不掛掉，就不重新選主。但是容易產生腦裂（雙主），為此，再通過「法定得票人數過半」解決腦裂問題

1、多數派原則：必須得到超過半數的選票才能成為master。
選出的leader一定擁有最新已提交數據：在raft中，數據更新的節點不會給數據舊的節點投選票，而當選需要多數派的選票，則當選人一定有最新已提交數據。在es中，version大的節點排序優先順序高，同樣用於保證這一點。

正確性論證：raft是一個被論證過正確性的演算法，而ES的演算法是一個沒有經過論證的演算法，只能在實踐中發現問題，做bug fix，這是我認為最大的不同。

是否有選舉周期term：raft引入了選舉周期的概念，每輪選舉term加1，保證了在同一個term下每個參與人只能投1票。ES在選舉時沒有term的概念，不能保證每輪每個節點只投一票。
選舉的傾向性：raft中只要一個節點擁有最新的已提交的數據，則有機會選舉成為master。在ES中，version相同時會按照NodeId排序，總是NodeId小的人優先順序高。

2、Paxos演算法
Paxos非常強大，尤其在什麼時機，以及如何進行選舉方面的靈活性比簡單的Bully演算法有很大的優勢，因為在現實生活中，存在比網路連接異常更多的故障模式。但 Paxos 實現起來非常復雜

本篇只討論內置的Zen Discovery

整體流程可以概括為：選舉臨時Master，如果本節點當選，則等待確立Master，如果其他節點當選，則嘗試加入集群，然後啟動節點失效探測器。

如果集群剛啟動則參與選主，否則加入集群
org.elasticsearch.node.Node.start()

選舉過程的實現位於 org.elasticsearch.discovery.zen.ZenDiscovery.findMaster() ,該函數查找當前集群的活躍 Master，或者從候選者中選擇新的Master。如果選主成功，則返回選定的Master，否則返回空

上面選擇臨時主節點非常簡單，
首先需要判斷當前候選者人數是否達到法定人數，否則選主失敗。

取列表中的最小值，比較函數通過compareNodes實現,只是對節點 ID 進行排序

選舉出的臨時Master有兩種情況：該臨時Master是本節點或非本節點。

（2）超時（默認為30秒，可配置）後還沒有滿足數量的join請求，則選舉失敗，需要進行新一輪選舉。

超時後直接return，當非臨時節點加入集群不成功時，重新發起選主流程
org.elasticsearch.discovery.zen.ZenDiscovery.innerJoinCluster()

（3）成功後發布新的clusterState。
實現如下：

submitStateUpdateTask最終通過TaskBatcher# submitTasks來提交任務。執行任務並發布集群狀態的總體過程在 MasterService#runTasks 方法中實現。

（2）向Master發送加入請求，並等待回復。超時時間默認為1分鍾（可配置），如果遇到異常，則默認重試3次（可配置）。這個步驟在joinElectedMaster方法中實現。

最終當選的Master會先發布集群狀態，才確認客戶的join請求，因此，joinElectedMaster返回代表收到了join請求的確認，並且已經收到了集群狀態。所以如果返回不成功，則重新發起選主流程
（3）檢查收到的集群狀態中的Master節點如果為空，或者當選的Master不是之前選擇的節點，則重新選舉。

1、es通過主從模式以及發現機制保證節點之間的負載均衡，但是es使用量的急劇增加暴露了很多問題，例如，Zen的minimum_master_nodes設置經常配置錯誤，這會使群集更容易出現裂腦和丟失數據的風險
2、7.x以上版本Coordinator提供了安全的亞秒級的master選舉時間，而Zen可能要花幾秒鍾來選擇一個新的master
3、es的master掛了，數據節點在這區間還能對外提供服務嗎？
參考
Elasticsearch分布式一致性原理剖析

㈨ es使用與原理6 -- 聚合分析剖析

有些聚合分析的演算法，是很容易就可以並行的，比如說max

有些聚合分析的演算法，是不好並行的，比如說，count(distinct)，並不是說，在每個node上，直接就出一些distinct value，就可以的，因為數據可能會很多，假設圖中的協調節點3百萬個數據去重後還剩下100萬distinct的數據，那麼內存需要來存儲這100萬條數據，這是不可能的

es會採取近似聚合的方式，就是採用在每個node上進行近估計的方式，得到最終的結論，cuont(distcint)，100萬，1050萬/95萬 --> 5%左右的錯誤率
近似估計後的結果，不完全准確，但是速度會很快，一般會達到完全精準的演算法的性能的數十倍

precision_threshold優化准確率和內存開銷

brand去重，如果brand的unique value，在100個以內，小米，長虹，三星，TCL，HTL。。。
在多少個unique value以內，cardinality，幾乎保證100%准確
cardinality演算法，會佔用precision_threshold * 8 byte 內存消耗，100 * 8 = 800個位元組
佔用內存很小。。。而且unique value如果的確在值以內，那麼可以確保100%准確
100，數百萬的unique value，錯誤率在5%以內
precision_threshold，值設置的越大，佔用內存越大，1000 * 8 = 8000 / 1000 = 8KB，可以確保更多unique value的場景下，100%的准確
field，去重，count，這時候，unique value，10000，precision_threshold=10000，10000 * 8 = 80000個byte，80KB

doc value正排索引
搜索+聚合 是怎麼實現的？
假設是倒排索引實現的

倒排索引來實現是非常不現實的，因為我們搜索的那個欄位search_field 有可能是分詞的，這就需要去掃描整個索引才能實現聚合操作，效率是及其低下的。
正排索引結構：
doc2: agg1
doc3: agg2
1萬個doc --> 搜 -> 可能跟搜索到10000次，就搜索完了，就找到了1萬個doc的聚合field的所有值了，然後就可以執行分組聚合操作了
doc value原理

1、doc value原理

（1）index-time生成

PUT/POST的時候，就會生成doc value數據，也就是正排索引

（2）核心原理與倒排索引類似

正排索引，也會寫入磁碟文件中，然後呢，os cache先進行緩存，以提升訪問doc value正排索引的性能
如果os cache內存大小不足夠放得下整個正排索引，doc value，就會將doc value的數據寫入磁碟文件中

（3）性能問題：給jvm更少內存，64g伺服器，給jvm最多16g

es官方是建議，es大量是基於os cache來進行緩存和提升性能的，不建議用jvm內存來進行緩存，那樣會導致一定的gc開銷和oom問題
給jvm更少的內存，給os cache更大的內存
64g伺服器，給jvm最多16g，幾十個g的內存給os cache
os cache可以提升doc value和倒排索引的緩存和查詢效率

2、column壓縮

doc1: 550
doc2: 550
doc3: 500

合並相同值，550，doc1和doc2都保留一個550的標識即可
（1）所有值相同，直接保留單值
（2）少於256個值，使用table encoding模式：一種壓縮方式
（3）大於256個值，看有沒有最大公約數，有就除以最大公約數，然後保留這個最大公約數

重點：
對分詞的field，直接執行聚合操作，會報錯，大概意思是說，你必須要打開fielddata，然後將正排索引數據載入到內存中，才可以對分詞的field執行聚合操作，而且會消耗很大的內存
先修改 欄位的fielddata屬性為true,再查 就能查找到數據

當然，我們也可以使用內置field(keyword)不分詞，對string field進行聚合,如果對不分詞的field執行聚合操作，直接就可以執行，不需要設置fieldata=true

分詞field+fielddata的工作原理

doc value --> 不分詞的所有field，可以執行聚合操作 --> 如果你的某個field不分詞，那麼在index-time，就會自動生成doc value --> 針對這些不分詞的field執行聚合操作的時候，自動就會用doc value來執行
分詞field，是沒有doc value的。。。在index-time，如果某個field是分詞的，那麼是不會給它建立doc value正排索引的，因為分詞後，佔用的空間過於大，所以默認是不支持分詞field進行聚合的
分詞field默認沒有doc value，所以直接對分詞field執行聚合操作，是會報錯的

對於分詞field，必須打開和使用fielddata，完全存在於純內存中。。。結構和doc value類似。。。如果是ngram或者是大量term，那麼必將佔用大量的內存。。。

如果一定要對分詞的field執行聚合，那麼必須將fielddata=true，然後es就會在執行聚合操作的時候，現場將field對應的數據，建立一份fielddata正排索引，fielddata正排索引的結構跟doc value是類似的，
但是只會講fielddata正排索引載入到內存中來，然後基於內存中的fielddata正排索引執行分詞field的聚合操作

如果直接對分詞field執行聚合，報錯，才會讓我們開啟fielddata=true，告訴我們，會將fielddata uninverted index，正排索引，載入到內存，會耗費內存空間

為什麼fielddata必須在內存？因為大家自己思考一下，分詞的字元串，需要按照term進行聚合，需要執行更加復雜的演算法和操作，如果基於磁碟和os cache，那麼性能會很差

我們是不是可以預先生成載入fielddata到內存中來？？？
query-time的fielddata生成和載入到內存，變為index-time，建立倒排索引的時候，會同步生成fielddata並且載入到內存中來，這樣的話，對分詞field的聚合性能當然會大幅度增強

㈩ es查詢數據的工作原理是什麼

查詢，GET某一條數據，寫入了某個document，這個document會自動給你分配一個全局唯一的id，doc id，同時也是根據doc id進行hash路由到對應的primary shard上面去。也可以手動指定doc id，比如用訂單id，用戶id。

我們可以通過doc id來查詢，會根據doc id進行hash，判斷出來當時把doc id分配到了哪個shard上面去，從那個shard去查詢

1）客戶端發送請求到任意一個node，成為coordinate node（協調結點）
2）coordinate node進行hash後對document進行路由，將請求轉發到對應的node，此時會使用round-robin 隨機輪詢演算法 ，在primary shard以及其所有replica node中 隨機選擇一個 ，讓讀請求負載均衡
3）接收請求的node返回document給coordinate node
4）coordinate node返回document給客戶端

es最強大的是做全文檢索，就是比如你有三條數據

java真好玩兒啊
java好難學啊
j2ee特別牛

你根據java關鍵詞來搜索，將包含java的document給搜索出來

es就會給你返回：java真好玩兒啊，java好難學啊

1）客戶端發送請求到一個coordinate node
2）協調節點 將搜索請求轉發到 所有的shard 對應的primary shard或replica shard
3）query phase： 每個shard將自己的搜索結果 （其實就是一些 doc id ）， 返回給協調節點 ，由協調節點進行數據的 合並、排序、分頁 等操作，產出最終結果
4）fetch phase：接著由 協調節點，根據doc id去各個節點上拉取實際的document數據 ，最終返回給客戶端

尤其要注意的這里是先拿的id喲