ElasticSearch13:partial update原理以及乐观锁并发控制

1.上几篇中提到了partial update的用法，这篇学习一下partial update的原理

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

在客户端中首先获取到es中的document，然后对部分数据进行修改，然后向es端发送请求进行修改，底层仍然是全量替换。

2.partial update并发问题

1）版本并发控制

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

可以通过version控制更新的数据的版本号

例子：

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