集群

集群的基本概念：

• 集群：ES 集群由一個或多個 Elasticsearch 節(jié)點組成，每個節(jié)點配置相同的 cluster.name 即可加入集群，默認(rèn)值為 “elasticsearch”。
• 節(jié)點：一個 Elasticsearch 服務(wù)啟動實例就是一個節(jié)點（Node）。節(jié)點分為主節(jié)點（Master），投票節(jié)點（Voting），協(xié)調(diào)節(jié)點（Coordinating），候選節(jié)點（Master-eligible）和數(shù)據(jù)節(jié)點（Data）。
• 分片：ES 支持 PB 級全文搜索，當(dāng)索引上的數(shù)據(jù)量太大的時候，ES 通過水平拆分的方式將一個索引上的數(shù)據(jù)拆分出來分配到不同的數(shù)據(jù)塊上，拆分出來的數(shù)據(jù)庫塊稱之為一個分片。
• 副本：副本就是對分片的 Copy，每個主分片都有一個或多個副本分片，當(dāng)主分片異常時，副本可以提供數(shù)據(jù)的查詢等操作。

如下圖可以看出為了達(dá)到高可用，Master 節(jié)點會避免將主分片和副本分片放在同一個節(jié)點上。

路由

1.? 寫請求首先會被打到協(xié)調(diào)節(jié)點，協(xié)調(diào)節(jié)點根據(jù)路由算法決定數(shù)據(jù)寫入的主分片位置，并在主節(jié)點上執(zhí)行寫入操作。

路由算法：

shardId = hash(_routing) % num_primary_shards

通過該公式可以保證使用相同routing的文檔被分配到同一個shard上。_routing 是一個可變值，默認(rèn)是文檔的?_id?，也可以設(shè)置成一個自定義的值，可以用在INDEX, UPDATE,GET, SEARCH, DELETE等各種操作中手動設(shè)置。

routing_partition_size參數(shù)

ES還提供了一個 index.routing_partition_size參數(shù)（僅當(dāng)使用routing參數(shù)時可用），用于將routing相同的文檔映射到集群分片的一個子集上，這樣一方面可以減少查詢的分片數(shù)，另一方面又可以在一定程度上防止數(shù)據(jù)傾斜。引入該參數(shù)后計算公式如下

shardId = (hash(_routing) + hash(_id) % routing_partition_size) % num_primary_shards

2.? 主分片執(zhí)行寫入操作，如下圖S0主分片寫入之后，同步到副本分片

索引寫入

主分片寫入

當(dāng)接收到請求時，執(zhí)行如下步驟：

? ? ①判斷操作類型：如果是 Bulk Request 會遍歷請求中的子操作，根據(jù)不同的操作類型跳轉(zhuǎn)到不同的處理邏輯。

? ? ②操作轉(zhuǎn)換：將 Update 操作轉(zhuǎn)換為 Index 和 Delete 操作。

? ? ③解析文檔（Parse Doc）：解析文檔的各字段。

? ? ④更新 Mapping：如果請求中有新增字段，會根據(jù) dynamic mapping 或 dynamic template 生成對應(yīng)的 mapping，如果 mapping 中有 dynamic mapping 相關(guān)設(shè)置則按設(shè)置處理。

? ? ⑤獲取 sequence Id 和 Version：從 SequenceNumberService 獲取一個 SequenceID 和 Version。SequenceID 用于初始化 LocalCheckPoint，version 是根據(jù)當(dāng)前 versoin+1 用于防止并發(fā)寫導(dǎo)致數(shù)據(jù)不一致（樂觀鎖）。

? ? ⑥寫入 Lucene：對索引文檔 uid 加鎖，然后判斷 uid 對應(yīng)的 version v2 和之前 update 轉(zhuǎn)換時的 version v1 是否一致，不一致則返回第二步重新執(zhí)行。在 version 一致的情況下根據(jù)id的情況執(zhí)行添加或者更新操作。如果同 id 的 doc 已經(jīng)存在，則調(diào)用 updateDocument 接口。

? ? ⑦寫入 translog：寫入 Lucene 的 Segment 后，會以 key value 的形式寫 Translog， Key 是 Id，Value 是索引文檔的內(nèi)容。當(dāng)查詢的時候，如果請求的是 GetDocById 則可以直接根據(jù) _id 從 translog 中獲取。寫入 translog 的操作會在下面的章節(jié)中詳細(xì)講解。

? ? ⑧重構(gòu) bulk request：已經(jīng)多個操作中的 update 操作轉(zhuǎn)換為 index、delete 操作，最終都以 index 或 delete 操作的方式組成 bulk request 請求。

? ? ⑨落盤 Translog：默認(rèn)情況下，translog 要在此處落盤完成，如果對可靠性要求不高，可以設(shè)置 translog 異步落盤，同時存在數(shù)據(jù)有丟失的風(fēng)險。

? ? ⑩發(fā)送請求給副本分片：將構(gòu)造好的 bulk request 發(fā)送給各個副本分片，并且等待副本分片返回，然后再響應(yīng)協(xié)調(diào)節(jié)點。如果某個分片執(zhí)行失敗，主分片會給主節(jié)點發(fā)請求移除該分片。

? ? ?等待 replica 響應(yīng)：當(dāng)所有的副本分片返回請求時，更新主分片的 LocalCheckPoint。如果設(shè)置了index.write.wait_for_active_shards=1,那么寫完主節(jié)點，直接返回客戶端，異步同步到從分片。如果 index.write.wait_for_active_shards=all,那么必須要把所有的副本寫入完成才返回客戶端。wait_for_active_shards最大值只能是?number_of_replicas?+1 ，詳情見官方文檔:https://www.elastic.co/guide/en/elasticsearch/reference/5.5/docs-index_.html#index-wait-for-active-shards

Elasticsearch?文件合并與刷新

? ? 在了解了文件寫入流程以后，再來近距離觀察一下寫入的細(xì)節(jié)，看看索引是如何通過內(nèi)存最終寫入磁盤的。

?如圖 2 所示，將每一步寫入操作進(jìn)行拆解如下：

? ? ①寫入請求會將索引（Index）存放到內(nèi)存區(qū)域，叫做 Index Buffer。這邊的內(nèi)存是ES JVM內(nèi)存。此時的索引文件暫時是不能被ES搜索到的。

? ? ②當(dāng)達(dá)到默認(rèn)的時間：1 秒鐘（參數(shù)refresh_interval=1s）或者內(nèi)存的數(shù)據(jù)達(dá)到一定量（默認(rèn)值是 JVM 所占內(nèi)存容量的 10%）時，會觸發(fā)一次刷新（Refresh），將內(nèi)存中的數(shù)據(jù)生成到一個新的段上并緩存到文件系統(tǒng)緩存（FileSystem Cache）上，并將Index Buffer 的數(shù)據(jù)會被清空。這時雖然新段未被提交到磁盤，但是此時的數(shù)據(jù)就可以被 ES 搜索到了且不能被修改。

? ? ③ES 每次 refresh 都會生成一個 Segment 文件，這樣下來 Segment 文件會越來越多。由于每個 Segment 都會占用文件句柄、內(nèi)存、CPU 資源，假設(shè)每次搜索請求都會訪問對應(yīng) Segment 獲取數(shù)據(jù)，這就意味著 Segment 越多會加大搜索請求的負(fù)擔(dān)，導(dǎo)致請求變慢。為了提高搜索性能 ES 會定期對 Segment 進(jìn)行合并（Merge）操作，也就是將多個小 Segment 合并成一個 Segment。那么搜索請求就直接訪問合并之后的 Segment，從而提高搜索性能。?

? ? ④上面 3 個步驟都是在內(nèi)存中完成的，此時數(shù)據(jù)還沒有寫到磁盤中。 隨著新文檔索引不斷被寫入，當(dāng)translog日志數(shù)據(jù)大小超過 512M （由 index.translog.flush_threshold_size 控制）或者時間超過 30 分鐘時，會觸發(fā)一次 Flush。此時 ES 會創(chuàng)建一個 Commit Point 文件，該文件用來標(biāo)識被 Flush 到磁盤上的 Segment。

Elasticsearch 數(shù)據(jù)存儲可靠性

延續(xù)上一節(jié)的例子，在原有的基礎(chǔ)上加入 Translog 的部分。如圖 3 所示，在整個 ES 寫入流程中加入 Translog，目的是為了提高 ES 的數(shù)據(jù)存儲可靠性。

? ? 索引文檔最開始是存放在內(nèi)存的 Index Buffer 中，當(dāng)執(zhí)行了 Refresh 操作會將其保存為 Segment，此時就可以供用戶查詢了。但是 Segment 在 Flush 之前仍然存在于內(nèi)存中，如果此時服務(wù)器宕機，而 ES 還沒有 Flush 操作保存在內(nèi)存中的 Segment 數(shù)據(jù)將會丟失。為了提高 ES 的數(shù)據(jù)存儲可靠性，引入了 Translog。在每次用戶請求 Index Buffer 進(jìn)行操作的時候都會寫一份操作記錄到 Translog 中，Translog 使用特有的機制保存到磁盤中。上一節(jié)提到的 Flush 操作，當(dāng) Flush 操作將 Segment 進(jìn)行落盤同時還會將 Translog 的文件進(jìn)行落盤，之后會將內(nèi)存中原有的Translog 移除，在內(nèi)存中會重新創(chuàng)建一個新的 Translog。

translog相關(guān)配置：

##translog的刷盤策略durability為request表示同步（默認(rèn)），async表示異步index.translog.durability: async
##translog刷盤間隔時間。默認(rèn)為5s，不可低于100msindex.translog.sync_interval: 120s
##超過這個大小會導(dǎo)致flush操作，產(chǎn)生新的Lucene分段。默認(rèn)值為512MBindex.translog.flush_threshold_size: 1024mb

通過這種方式當(dāng)斷電或需要重啟時，ES 不僅要根據(jù)提交點去加載已經(jīng)持久化過的段，還需要工具 Translog 里的記錄，把未持久化的數(shù)據(jù)重新持久化到磁盤上，避免了數(shù)據(jù)丟失的可能。

圖中 Translog 存在于內(nèi)存和磁盤中，分別有兩個線將其相連，表示了 Translog 同步的兩種方式：

• 在 ES 處理用戶請求時追加 Translog，追加的內(nèi)容就是對ES的請求操作。此時會根據(jù)配置同步或者異步的方式將操作記錄追加信息保存到磁盤中。

• 另一種 Translog 從內(nèi)存到磁盤的操作是在 Flush 發(fā)生的時候，上節(jié)中介紹過，Flush 操作會把 Segment 保存到磁盤同時還會將 Translog 的文件進(jìn)行落盤。落盤以后存在與內(nèi)存中的 Translog 就會被移除。

索引檢索

在執(zhí)行文檔的CRUD操作時，通過文檔ID就能計算出文檔存儲在哪個分片中，所以只要將客戶端請求轉(zhuǎn)發(fā)給對應(yīng)的分片(或其副本)所在的節(jié)點進(jìn)行處理即可。

而執(zhí)行文檔搜索操作時只會提供搜索條件，并不包含文檔ID，無法直接知道哪些分片包含搜索結(jié)果，需要先搜索所有的分片(或其副本)，還要對每個分片上的結(jié)果進(jìn)行匯總以得到最終結(jié)果。所以，文檔的搜索過程會分為如下兩步執(zhí)行：

1. 搜索所有的分片(或其副本)，確定哪些文檔屬于搜索結(jié)果；

2. 從相關(guān)分片上讀取文檔數(shù)據(jù)，再匯總組裝成最終的結(jié)果；

將第一步稱為query，第二步稱為fetch，整個搜索過程稱為query-then-fetch。

以分頁查詢?yōu)槔?#xff0c;from + size 分頁方式是 ES 最基本的分頁方式，類似于關(guān)系型數(shù)據(jù)庫中的 limit 方式。from 參數(shù)表示：分頁起始位置；size 參數(shù)表示：每頁獲取數(shù)據(jù)條數(shù)。例如：

{"query": {"match_all": {}},"from": 10,"size": 20
}

Query階段

如上圖所示，Query 階段大致分為 3 步：

• 第一步：Client 發(fā)送查詢請求到 Server 端，Node1 接收到請求然后創(chuàng)建一個大小為 from + size的優(yōu)先級隊列用來存放結(jié)果，此時 Node1 被稱為 coordinating node（協(xié)調(diào)節(jié)點）；

• 第二步：Node1 將請求廣播到涉及的 shard （主分片或副本分片，根據(jù)隨機或輪詢算法）上，每個 shard 內(nèi)部執(zhí)行搜索請求，然后將執(zhí)行結(jié)果存到自己內(nèi)部的大小同樣為 from+size 的優(yōu)先級隊列里；

• 第三步：每個 shard 將暫存的自身優(yōu)先級隊列里的結(jié)果返給 Node1，Node1 拿到所有 shard 返回的結(jié)果后，對結(jié)果進(jìn)行一次合并，產(chǎn)生一個全局的優(yōu)先級隊列，存在 Node1 的優(yōu)先級隊列中。（如上圖中，Node1 會拿到 (from + size) * 6 條數(shù)據(jù)，這些數(shù)據(jù)只包含 doc 的唯一標(biāo)識_id 和用于排序的_score，然后 Node1 會對這些數(shù)據(jù)合并排序，選擇前 from + size 條數(shù)據(jù)存到優(yōu)先級隊列）；

Fetch階段

如上圖所示，當(dāng) Query 階段結(jié)束后立馬進(jìn)入 Fetch 階段，Fetch 階段也分為 3 步：

• 第一步：Node1 根據(jù)剛才合并后保存在優(yōu)先級隊列中的 from+size 條數(shù)據(jù)的 id 集合，發(fā)送請求到對應(yīng)的 shard 上查詢 doc 數(shù)據(jù)詳情；

• 第二步：各 shard 接收到查詢請求后，查詢到對應(yīng)的數(shù)據(jù)詳情并返回為 Node1；（Node1 中的優(yōu)先級隊列中保存了 from + size 條數(shù)據(jù)的_id，但是在 Fetch 階段并不需要取回所有數(shù)據(jù)，只需要取回從 from 到 from + size 之間的 size 條數(shù)據(jù)詳情即可，這 size 條數(shù)據(jù)可能在同一個 shard 也可能在不同的 shard，因此 Node1 使用 multi-get 來提高性能）

• 第三步：Node1 獲取到對應(yīng)的分頁數(shù)據(jù)后，返回給 Client；

索引修改和刪除

? ? 索引文件分段存儲并且不可修改，那么新增、更新和刪除如何處理呢？

• 刪除操作?：commit?的時候會生成一個?.del?文件，里面將某個?doc?標(biāo)識為?deleted狀態(tài)，那么搜索的時候根據(jù)?.del?文件就知道這個 doc 是否被刪除了，最終結(jié)果被返回前從結(jié)果集中移除。

• 更新操作?：就是將原來的?doc?標(biāo)識為?deleted?狀態(tài)，然后新寫入一條數(shù)據(jù)。

merge?操作時會將多個?segment file?合并成一個，同時將標(biāo)識為?deleted?的?doc「物理刪除」?，將新的?segment file?寫入磁盤，最后打上?commit point?標(biāo)識所有新的?segment file。