在 Elasticsearch 中,使用 PUT 請求存儲一條數據(即索引一個文檔)是一個涉及多個組件的復雜過程,它不僅包括數據的存儲,還涵蓋了數據處理、路由、復制等一系列服務。下面我們將詳細解析從發起 PUT 請求到數據最終落地的完整流程。
1. 客戶端發起請求
用戶通過 REST API 向 Elasticsearch 集群發送一個 PUT 請求,其基本格式為:PUT /<index>/_doc/<id>。其中 <index> 是目標索引名稱,<id> 是指定的文檔 ID(如果省略,Elasticsearch 會自動生成一個)。請求體包含了要存儲的 JSON 格式文檔數據。
2. 請求到達協調節點
Elasticsearch 集群中的任意節點都可以接收請求,這個節點被稱為“協調節點”。協調節點負責處理客戶端的請求,并將其路由到正確的數據節點。它首先會解析請求,檢查索引是否存在、映射是否定義等。如果索引是自動創建的(根據配置),協調節點會觸發索引的創建過程。
3. 文檔路由與主分片定位
Elasticsearch 索引由一個或多個主分片(及可選的副本分片)組成。協調節點根據文檔 ID 計算其應該存儲在哪個主分片上。默認的路由算法是:shard<em>num = hash(</em>routing) % num<em>primary</em>shards,其中 _routing 默認為文檔 ID。通過計算,協調節點確定目標主分片及其所在的數據節點(稱為“主分片節點”)。
4. 轉發請求到主分片節點
協調節點將索引請求轉發到上一步確定的主分片節點。此時,主分片節點開始本地的索引處理流程。
5. 本地索引處理(數據處理階段)
在主分片節點上,數據會經歷一系列處理步驟:
- 解析與驗證:系統解析 JSON 文檔,驗證其結構。
- 字段映射與類型轉換:根據索引的映射(mapping)定義,對字段進行類型處理。例如,將字符串日期轉換為
date類型,或對文本字段進行分詞設置。如果字段未預先定義且動態映射開啟,Elasticsearch 會自動推斷其類型并更新映射。 - 分析過程:對于文本字段(
text類型),會調用相應的分析器(analyzer)進行分詞、過濾(如小寫化、去除停用詞等),生成倒排索引所需的詞項。 - 生成文檔數據結構:處理后的文檔會被轉換為內部存儲結構,包括源文檔(
_source,默認存儲原始 JSON)、倒排索引條目、文檔值(用于排序和聚合)等。
6. 寫入事務日志與內存緩沖區
為確保數據的持久性和一致性,Elasticsearch 采用了以下步驟:
- 事務日志(Translog)寫入:在數據真正寫入磁盤前,操作會首先被記錄到事務日志中。Translog 提供了崩潰恢復機制,防止數據丟失。
- 內存緩沖區:文檔數據被添加到索引的內存緩沖區中,此時尚不可被搜索。
7. 刷新(Refresh)與可搜索性
內存緩沖區會定期刷新(默認每 1 秒一次,可通過 refresh_interval 配置)。刷新過程會:
- 將內存緩沖區中的內容寫入一個新的段(segment)中,這是一個輕量級的提交。
- 重新打開索引,使得新段內的文檔變得可搜索。
注意:刷新操作不會立即將數據持久化到磁盤,而是先寫入文件系統緩存,速度較快。
8. 副本同步(存儲支持服務的關鍵)
如果索引配置了副本分片(replica shards),主分片節點在本地處理完成后,會將索引請求并行轉發到所有副本分片所在的節點。副本分片執行相同的本地索引處理流程。只有當所有副本分片也成功完成操作后(或根據配置的 consistency 級別),主分片節點才會向協調節點報告成功。這提供了數據的高可用性和容錯能力。
9. 響應客戶端
協調節點收到主分片節點的成功響應后,會向客戶端返回一個確認,通常包含索引名稱、文檔 ID、版本號以及操作結果(如 "result": "created")。
10. 后續持久化:刷寫(Flush)與段合并
為了數據的長期持久化,Elasticsearch 會定期執行刷寫操作:
- Translog 刷寫:當 Translog 達到一定大小時(默認 512MB)或定期(默認 30 分鐘),會觸發一次刷寫。此時,內存中所有未持久化的段會被完全寫入磁盤,同時清空 Translog。
- 段合并:由于頻繁刷新會產生大量小段,Elasticsearch 會在后臺自動合并小段為更大的段,優化存儲和搜索性能,并刪除已刪除的文檔。
###
Elasticsearch 的 PUT 過程是一個分布式、多階段的數據處理與存儲流程。它巧妙地將數據路由、實時處理(映射、分析)、內存緩沖、事務日志、刷新與刷寫機制,以及副本復制結合起來,在保證性能、可搜索性和可靠性的提供了強大的數據存儲支持服務。理解這一流程有助于更好地設計索引、調優性能和診斷問題。