ElasticSearch13:partial update原理以及樂觀鎖併發控制
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