1.上幾篇中提到了partial update的用法，這篇學習一下partial update的原理

和全量替換的原理稍有不同，partial update的原理：

在客戶端中首先獲取到es中的document，然後對部分資料進行修改，然後向es端傳送請求進行修改，底層仍然是全量替換。

2.partial update併發問題

1）版本併發控制

POST /index/type/id/_update?version=6

例子：

POST /test_index/test_type/10/_update?version=5
{
  "doc": {
  "test_field":"test_201712291047"
  }
}

當前的版本號為6，上面的操作就會報錯

{
  "error": {
    "root_cause": [
      {
        "type": "version_conflict_engine_exception",
        "reason": "[test_type][10]: version conflict, current version [6] is different than the one provided [5]",
        "index_uuid": "ZnZjGP7GQsqotz19lqhxJg",
        "shard": "1",
        "index": "test_index"
      }
    ],
    "type": "version_conflict_engine_exception",
    "reason": "[test_type][10]: version conflict, current version [6] is different than the one provided [5]",
    "index_uuid": "ZnZjGP7GQsqotz19lqhxJg",
    "shard": "1",
    "index": "test_index"
  },
  "status": 409
}

2）樂觀鎖併發控制策略：retry策略

POST /test_index/test_type/10/_update?retry_on_conflict=5

retry策略

1）再次獲取document資料和最新版本號

2）基於最新版本號再次更新，如果成功那麼就ok了

3）如果失敗，重複1,2步驟，最多重複次數可以通過retry的引數決定,retry_on_conflict=5表示最多重複5次

例子：此時，es中該資料的版本號為6，而請求中的version為5，比較後發現不同，就去系統獲取最新的版本進行更新操作，繼續判斷版本號是否相同，如果相同則進行更新操作，如果不相同，那麼繼續獲取最新版本號進行更新操作，持續操作這個步驟，持續次數為retry_on_conflict