1. 程式人生 > >ES 17 - (底層原理) Elasticsearch增刪改查索引數據的過程

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

創建 primary enc 協調 轉載 頁面 所有 ima 強調

目錄

  • 1 增刪改document的流程
    • 1.1 協調節點 - Coordinating Node
    • 1.2 增刪改document的流程
  • 2 查詢document的流程

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

版權聲明

作者: 馬瘦風

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

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

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

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