## 局部更新文檔 `update` API 結合了之前提到的讀和寫的模式。  下面我們羅列執行局部更新必要的順序步驟： 1. 客戶端給`Node 1`發送更新請求。 2. 它轉發請求到主分片所在節點`Node 3`。 3. `Node 3`從主分片檢索出文檔，修改`_source`字段的JSON，然后在主分片上重建索引。如果有其他進程修改了文檔，它以`retry_on_conflict`設置的次數重復步驟3，都未成功則放棄。 4. 如果`Node 3`成功更新文檔，它同時轉發文檔的新版本到`Node 1`和`Node 2`上的復制節點以重建索引。當所有復制節點報告成功，`Node 3`返回成功給請求節點，然后返回給客戶端。 `update` API還接受《新建、索引和刪除》章節提到的`routing`、`replication`、`consistency`和`timout`參數。 > ### 基于文檔的復制 > 當主分片轉發更改給復制分片時，并不是轉發更新請求，而是轉發整個文檔的新版本。記住這些修改轉發到復制節點是異步的，它們并不能保證到達的順序與發送相同。如果Elasticsearch轉發的僅僅是修改請求，修改的順序可能是錯誤的，那得到的就是個損壞的文檔。