在 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 過程是一個分布式、多階段的數據處理與存儲流程。它巧妙地將數據路由、實時處理（映射、分析）、內存緩沖、事務日志、刷新與刷寫機制，以及副本復制結合起來，在保證性能、可搜索性和可靠性的提供了強大的數據存儲支持服務。理解這一流程有助于更好地設計索引、調優性能和診斷問題。
