### 更新文檔中的一部分 The `update` API combines the read and write patterns explained above. [[img-distrib-update]].Partial updates to a documentimage::images/04-04_update.png["Partial updates to a document"] Below we list the sequence of steps used to perform a partial update on adocument, as depicted in <>: 1. The client sends an update request to `Node_1`. 1. It forwards the request to `Node 3`, where the primary shard is allocated. 1. `Node 3` retrieves the document from the primary shard, changes the JSONin the `_source` field, and tries to reindex the document on the primaryshard. If the document has already been changed by another process, itretries step 3 up to `retry_on_conflict` times, before giving up. 1. If `Node 3` has managed to update the document successfully, it forwardsthe new version of the document in parallel to the replica shards on `Node1` and `Node 2` to be reindexed. Once all replica shards report success,`Node 3` reports success to the requesting node, which reports success tothe client. The `update` API also accepts the `routing`, `replication`, `consistency` and`timeout` parameters that are explained in <>. > ### 基于文檔的復制 When a primary shard forwards changes to its replica shards, it doesn'tforward the update request. Instead it forwards the new version of the fulldocument. Remember that these changes are forwarded to the replica shardsasynchronously and there is no guarantee that they will arrive in the sameorder that they were sent. If Elasticsearch forwarded just the change, it ispossible that changes would be applied in the wrong order, resulting in acorrupt document.