ES 17 - (底層原理) Elasticsearch增刪改查索引數據的過程

[TOC]

1 增刪改document的流程

1.1 協調節點 - Coordinating Node

Coordinating Node(協調節點): 客戶端隨機選擇一個Node用來發送操做請求, 這個節點就稱爲協調節點.

因爲每一個Node都能計算出Document的存儲位置, 因此由哪一個Node擔任協調節點都是能夠的——這對客戶端來講是透明的.

1.2 增刪改document的流程

① 客戶端經過協調節點發送 增刪改請求.

② 協調節點對客戶端提交的文檔進行路由, 而後將相關請求轉發到 存儲該文檔的Primary Shard上.

③ Primary Shard處理客戶端的請求, 而後將操做後的Document同步到其對應的Replica Shard中.

④ 協調節點監控到Primary Shard和其對應的Replica Shard都處理完了該Document, (協調節點)就將操做結果響應給客戶端.

強調: 增刪改操做只能由Primary Shard處理, Replica Shard只能處理查詢請求.

2 查詢document的流程

(1) 流程:

① 客戶端經過協調節點發送 查詢請求.

② 協調節點對客戶端提交的文檔進行路由, 明確存儲相關文檔的Primary Shard(主分片), 而後使用Round-Robin算法(隨機輪訓算法), 將查詢請求轉發到 該Primary Shard及這個主分片對應的任意一個Replica Shard(副本分片) —— 讀請求的負載均衡.

③ 接收到查詢請求的Shard執行該請求, 而後將查詢結果響應給協調節點.

④ 協調節點將查詢結果響應給客戶端.

(2) 特殊狀況說明:

若是某個Document正在Primary Shard中創建索引, 其餘Replica Shard尚未來得及同步此索引, 而協調節點卻將查詢請求轉發到了某個這樣的Replica Shard上, 就會出現 沒有查到這個Document 的狀況.

當Document完成索引的建立以後, Primary Shard和Replica Shard中就都有相關數據了.

強調: Replica Shard只能處理讀(查詢)請求.

參考資料

Elasticsearch 6.6 官方文檔 - Coordinating node

版權聲明

做者: 馬瘦風

出處: 博客園 馬瘦風的博客

您的支持是對博主的極大鼓勵, 感謝您的閱讀.

本文版權歸博主全部, 歡迎轉載, 但請保留此段聲明, 並在文章頁面明顯位置給出原文連接, 不然博主保留追究相關人員法律責任的權利.