2. 程式人生 > >Elasticsearch 基於external的樂觀鎖的版本控制

Elasticsearch 基於external的樂觀鎖的版本控制

阿新 • • 發佈：2019-01-16
es，_version=1，?version=1，才能更新成功
es，_version=1，?version>1&version_type=external，才能成功，比如說?version=2&version_type=external


（1）先構造一條資料


PUT /test_index/test_type/8
{
  "test_field": "test"
}


{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "8",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": true
}


（2）模擬兩個客戶端同時查詢到這條資料


GET /test_index/test_type/8


{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "8",
  "_version": 1,
  "found": true,
  "_source": {
    "test_field": "test"
  }
}


（3）第一個客戶端先進行修改，此時客戶端程式是在自己的資料庫中獲取到了這條資料的最新版本號，比如說是2


PUT /test_index/test_type/8?version=2&version_type=external
{
  "test_field": "test client 1"
}


{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "8",
  "_version": 2,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": false
}


（4）模擬第二個客戶端，同時拿到了自己資料庫中維護的那個版本號，也是2，同時基於version=2發起了修改


PUT /test_index/test_type/8?version=2&version_type=external
{
  "test_field": "test client 2"
}


{
  "error": {
    "root_cause": [
      {
        "type": "version_conflict_engine_exception",
        "reason": "[test_type][8]: version conflict, current version [2] is higher or equal to the one provided [2]",
        "index_uuid": "6m0G7yx7R1KECWWGnfH1sw",
        "shard": "1",
        "index": "test_index"
      }
    ],
    "type": "version_conflict_engine_exception",
    "reason": "[test_type][8]: version conflict, current version [2] is higher or equal to the one provided [2]",
    "index_uuid": "6m0G7yx7R1KECWWGnfH1sw",
    "shard": "1",
    "index": "test_index"
  },
  "status": 409
}


（5）在併發控制成功後，重新基於最新的版本號發起更新


GET /test_index/test_type/8


{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "8",
  "_version": 2,
  "found": true,
  "_source": {
    "test_field": "test client 1"
  }
}


PUT /test_index/test_type/8?version=3&version_type=external
{
  "test_field": "test client 2"
}


{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "8",
  "_version": 3,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": false
}

相關推薦

Elasticsearch 基於external的樂觀鎖的版本控制

es，_version=1，?version=1，才能更新成功 es，_version=1，?version>1&version_type=external，才能成功，比如說?version=2&version_type=external （1）先構造一條資料 PUT /test_ind

ES:partial update 原理、 基於groovy使用、 內建樂觀鎖併發控制

1、partial update基本語法 POST /index/type/id/_update { "doc" : { "要修改的少數幾個field即可，不需要全量的資料" } } 每次就傳遞少數幾個發生修改的field即可，不需要將全量的docu

ES:基於_version進行樂觀鎖併發控制

圖示的衝突過程，其實就是es的併發衝突問題，會導致資料不準確 當併發操作es的執行緒越多，或者讀取一份資料，供使用者查詢和操作的時間越長，在這段時間裡，如果資料被其他使用者修改，那麼我們拿到的就是舊資料，基於舊資料去操作，就會導致錯誤的結果 1、悲觀鎖與樂觀鎖兩種併發

ElasticSearch最佳入門實踐（二十四）partial update樂觀鎖併發控制原理以及相關操作

（1）partial update內建樂觀鎖併發控制 partial update內部是自動執行之前所說的樂觀鎖的併發控制方案 兩個執行緒 都拿到了document資料和_version 使用傳過來的field更新document 執行緒B也在做partial update

Elasticsearch更新重複提交和版本控制（併發問題）

1.樂觀鎖 Elasticsearch 使用這個 _version 號來確保變更以正確順序得到執行。如果舊版本的文件在新版本之後到達，它可以被簡單的忽略。 我們可以利用 _version 號來確保 應用中相互衝突的變更不會導致資料丟失。我們通過指定想要修改文件的

ElasticSearch13:partial update原理以及樂觀鎖併發控制

1.上幾篇中提到了partial update的用法，這篇學習一下partial update的原理 和全量替換的原理稍有不同，partial update的原理： 在客戶端中首先獲取到es中的document，然後對部分資料進行修改，然後向es端傳送請求進行修改，底層仍然

樂觀鎖版本機制+100個併發讀取資料修改資料

package com.lock;import java.sql.Connection;import java.sql.DriverManager;import java.sql.PreparedStatement;import java.sql.ResultSet;impo

Elasticsearch 基於樂觀鎖的版本控制

（1）先構造一條資料出來 PUT /test_index/test_type/7 {   "test_field": "test test" } （2）模擬兩個客戶端，都獲取到了同一條資料 GET test_index/test_type/7 {   "_index": "test_index",   "_t

基於external version進行樂觀鎖並發控制

行修改 樂觀鎖 nal div type 基於 gpo 區別 並發 ?version=1?version=1&version_type=external它們的唯一區別在於，_version，只有當你提供的version與es中的_version一模一樣的時候，才可以

elasticsearch 筆記七: es樂觀鎖的併發控制

1.併發控制 es 的併發控制是通過多version來實現的(不清楚樂觀鎖的自己提升去) 2.例項 //建立索引 PUT /test_index/test_type/7 { "test_field": "test test" } //返回建立結果 GET test_index

hibernate版本控制 樂觀鎖悲觀鎖

//1: 資料庫表 people 加上一列  version int //2:  實體類  people 屬性 ( private  int version;) //3:  在hibernate 對映檔案class 之間  在一個表示副 id 之後加上  <version    cloumn="vers

Elasticsearch系列---併發控制及樂觀鎖實現原理

概要 本篇主要介紹一下Elasticsearch的併發控制和樂觀鎖的實現原理，列舉常見的電商場景，關係型資料庫的併發控制、ES的併發控制實踐。 併發場景 不論是關係型資料庫的應用，還是使用Elasticsearch做搜尋加速的場景，只要有資料更新，併發控制是永恆的話題。 當我們使用ES更新document的時

基於GitLab與Git Extensions搭建版本控制工具

基本 cmd img html nat 需求 無法 spa hang 1.背景 　　大家知道GitHub是現在非常流行的代碼托管工具，但是如果有些項目不想開源的話，則需要付費，因此萌生了自己搭建一個Git的版本控制工具，供內網使用。GitLab則是個好的選擇，但是GitL

ELK 學習筆記之 elasticsearch 版本控制

如果 curl version last ges 外部 upd put image 版本控制： elasticsearch 版本控制： 內部版本控制 外部版本控制 內部版本控制： 內部版本會檢查你提供的版本值和文檔的版本值是否一致，如果不一致就報錯，一致則可以更

Elasticsearch的樂觀並發控制和分片管理(更新中)

fresh 控制 新版本 ... 文檔 順序 搜索 per 並發 1. 樂觀並發控制 　　首先，需要明確Elasticsearch的三個特性： 分布式的：當文檔創建，刪除或更新的時候，新版本的文檔必須被復制到集群中的其他節點； 並發的：這些復制請求將被並行發送； 異步的：

Centos 7.X 部署基於Git&Gitolite的分布式版本控制系統

git gitolite 版本控制系統 甘兵 1、簡介1.1 git 簡介 Linus在1991年創建了開源的Linux，從此，Linux系統不斷發展，已經成為最大的服務器系統軟件了。Linus雖然創建了Linux，但Linux的壯大是靠全世界熱心的誌願者參與的，這麽多人在世界各地為Li

25.partial update內置樂觀鎖並發控制

sans 沖突 amp 數據返回 update gpo tro 知識點 把他 主要知識點 （1）partial update內置樂觀鎖並發控制 （2）retry_on_conflict post /index/type/id/_update?ret

java10:基於時間的版本控制

取代 spa 兼容 才會 語言 遞增 如果 靈活 改進 功能發布 從Java 10開始，采用了一種新的嚴格的基於時間的發布模式。 在這個新模型中，Java平臺的主要版本（現稱為功能版本）將每6個月（3月和9月）發布一次。 功能版本將包含語言功能，JVM功能和新的改進的API

基於 Git實現版本控制

一，什麼是版本控制? 版本控制是指對軟體開發過程中各種程式程式碼、配置檔案及說明文件等檔案變更的管理，是軟體配置管理的核心思想之一。 在進行專案開發過程中,你是否會有下面的經歷? 當客戶需求改變時，需要重新對專案進行修改。又怕將來客戶撤銷這個需求怎麼辦？只能把

ElasticSearch學習筆記十七 文件更新及版本控制

文件更新 在 Elasticsearch 中文件是 不可改變 的，不能修改它們。相反，如果想要更新現有的文件，需要 重建索引。但是我們不需要自己來完成操作，Update API 會幫我們完成。 例如我們新插入一條紀錄 PUT /website/blog/1 {