當我們使用 index API 更新文檔 ，可以一次性讀取原始文檔做我們的修改，然后重新索引整個文檔 。 最近的索引請求將獲勝：無論最后哪一個文檔被索引，都將被唯一存儲在 Elasticsearch 中。如果其他人同時更改這個文檔，他們的更改將丟失。 <br/> 很多時候這是沒有問題的。也許我們的主數據存儲是一個關系型數據庫，我們只是將數據復制到 Elasticsearch 中并使其可被搜索。 也許兩個人同時更改相同的文檔的幾率很小。或者對于我們的業務來說偶爾丟失更改并不是很嚴重的問題。 <br/> 但有時丟失了一個**變更**就是非常嚴重的 。試想我們使用 Elasticsearch 存儲我們網上商城商品庫存的數量， 每次我們賣一個商品的時候，我們在 Elasticsearch 中將庫存數量減少。有一天，管理層決定做一次促銷。突然地，我們一秒要賣好幾個商品。 假設有兩個 web 程序并行運行，每一個都同時處理所有商品的銷售。 :-:  web_1 對 stock_count 所做的更改已經丟失，因為 web_2 不知道它的 stock_count 的拷貝已經過期。 結果我們會認為還有庫存，但實際上已經沒有庫存了，賣給用戶一個已經沒有庫存商品的情況是非常槽糕的。 <br/> 變更越頻繁，讀數據和更新數據的間隙越長，也就越可能丟失變更。 <br/> 在數據庫領域中，有兩種方法通常被用來確保并發更新時變更不會丟失： （1）悲觀并發控制 這種方法被關系型數據庫廣泛使用，它假定有變更沖突可能發生，因此阻塞訪問資源以防止沖突。 一個典型的例子是讀取一行數據之前先將其鎖住，確保只有放置鎖的線程能夠對這行數據進行修改。 （2）樂觀并發控制 Elasticsearch 中使用的這種方法假定沖突是不可能發生的，并且不會阻塞正在嘗試的操作。 然而，如果源數據在讀寫當中被修改，更新將會失敗。應用程序接下來將決定該如何解決沖突。 例如，可以重試更新、使用新的數據、或者將相關情況報告給用戶。