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只能處理讀(查詢)請求.
參考資料
版權聲明
作者: 馬瘦風
出處: 博客園 馬瘦風的博客
您的支持是對博主的極大鼓勵, 感謝您的閱讀.
本文版權歸博主所有, 歡迎轉載, 但請保留此段聲明, 並在文章頁面明顯位置給出原文鏈接, 否則博主保留追究相關人員法律責任的權利.