ElasticSearch(九)基于version进行乐观锁并发控制

一、基于version进行乐观锁并发控制

1)、查看一条document

GET /test_version/test_version_type/1
{
  "_index" : "test_version",
  "_type" : "test_version_type",
  "_id" : "1",
  "_version" : 1,
  "found" : true,
  "_source" : {
    "test_field" : "test test"
  }
}

2)、模拟多并发下,利用version进行更新

同时带上数据的版本号,确保说,es中的数据的版本号,跟客户端中的数据的版本号是相同的,才能修改

PUT /test_version/test_version_type/1?version=1
{
  "test_field": "test client 1"
}

{
  "_index" : "test_version",
  "_type" : "test_version_type",
  "_id" : "1",
  "_version" : 2,
  "result" : "updated",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 1,
  "_primary_term" : 1
}
PUT /test_version/test_version_type/1?version=1
{
  "test_field": "test client 2"
}

{
  "error": {
    "root_cause": [
      {
        "type": "version_conflict_engine_exception",
        "reason": "[test_version_type][1]: version conflict, current version [2] is different than the one provided [1]",
        "index_uuid": "VT8uFhvTS_qawAksysahtQ",
        "shard": "3",
        "index": "test_version"
      }
    ],
    "type": "version_conflict_engine_exception",
    "reason": "[test_version_type][1]: version conflict, current version [2] is different than the one provided [1]",
    "index_uuid": "VT8uFhvTS_qawAksysahtQ",
    "shard": "3",
    "index": "test_version"
  },
  "status": 409
}

二、基于external version进行乐观锁并发控制

es提供了一个feature,就是说,你可以不用它提供的内部_version版本号来进行并发控制,可以基于你自己维护的一个版本号来进行并发控制。

1)、查看一条document

GET /test_version/test_version_type/2
{
  "_index" : "test_version",
  "_type" : "test_version_type",
  "_id" : "2",
  "_version" : 1,
  "found" : true,
  "_source" : {
    "test_field" : "test"
  }
}

2)、语法与区别

?version=1
?version=1&version_type=external

version_type=external,唯一的区别在于,_version,只有当你提供的version与es中的_version一模一样的时候,才可以进行修改,只要不一样,就报错;当version_type=external的时候,只有当你提供的version比es中的_version大的时候,才能完成修改

3)、模拟多并发下,利用version进行更新

PUT /test_version/test_version_type/3?version=2&version_type=external
{
  "test_field": "test client 1"
}

{
  "_index" : "test_version",
  "_type" : "test_version_type",
  "_id" : "3",
  "_version" : 2,
  "result" : "updated",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 1,
  "_primary_term" : 1
}
PUT /test_version/test_version_type/3?version=2&version_type=external
{
  "test_field": "test client 2"
}

{
  "error": {
    "root_cause": [
      {
        "type": "version_conflict_engine_exception",
        "reason": "[test_version_type][3]: version conflict, current version [2] is higher or equal to the one provided [2]",
        "index_uuid": "VT8uFhvTS_qawAksysahtQ",
        "shard": "4",
        "index": "test_version"
      }
    ],
    "type": "version_conflict_engine_exception",
    "reason": "[test_version_type][3]: version conflict, current version [2] is higher or equal to the one provided [2]",
    "index_uuid": "VT8uFhvTS_qawAksysahtQ",
    "shard": "4",
    "index": "test_version"
  },
  "status": 409
}

原文地址:https://www.cnblogs.com/ql211lin/p/10271123.html

时间: 2024-11-02 05:33:23

ElasticSearch(九)基于version进行乐观锁并发控制的相关文章

ElasticSearch 并发冲突+悲观锁与乐观锁+基于_version和external version进行乐观锁并发控制

1.图解剖析Elasticsearch并发冲突问题 2.图解剖析悲观锁与乐观锁两种并发控制方案 3.图解Elasticsearch内部如何基于_version进行乐观锁并发控制 (1)_version元数据 PUT /test_index/test_type/6{ "test_field": "test test"} { "_index": "test_index", "_type": "test

基于external version进行乐观锁并发控制

?version=1?version=1&version_type=external它们的唯一区别在于,_version,只有当你提供的version与es中的_version一模一样的时候,才可以进行修改,只要不一样就报错:当version_type=external的时候,只有当你提供的version比es中的_version大的时候,才能完成修改. 比如:es中的_version=1?version=1 能更新成功?version>1&version_type=external

乐观锁是基于比较的无锁并发控制机制

乐观锁是基于比较的无锁并发控制机制. CAS mvcc The general idea is this: Optimistic locking Each table you want to implement concurrent access to need a new column: Version. This column is usually an integer or a timestamp. Every time a record in the table changes, its

25.partial update内置乐观锁并发控制

主要知识点 (1)partial update内置乐观锁并发控制 (2)retry_on_conflict post /index/type/id/_update?retry_on_conflict=5&version=6 一.一般情况下partial update实现过程 用户直接修改field,然后发送给应用程序,由应用程序直接发送给ES,和全量替换相比,全量替换要先去es进行查找,把查找的数据返回给应用程序,然后再次返回给用户界面,只有这样用户才知道要替换什么,partial update

6:Partial Update 内部原理 和 乐观锁并发控制

Partial Update 内部执行过程: 首先,ES文档是不可变的,它们只能被修改,不能被替换.Update Api 也不例外. Update API 简单使用与之前描述相同的 检索-修改-重建索引(reindex) 的处理过程. 区别在于这个过程发生在分片内部. 相当于ES的Shard内部 执行了 Get(获取该文档所有数据),CreateDoc(根据请求生成新文档),Put(把新文档写入ES).如果使用全量替换,这3个步骤会发生在Java程序里,但如果使用partial update,E

AtomicInteger源码分析——基于CAS的乐观锁实现

AtomicInteger源码分析--基于CAS的乐观锁实现 1. 悲观锁与乐观锁 我们都知道,cpu是时分复用的,也就是把cpu的时间片,分配给不同的thread/process轮流执行,时间片与时间片之间,需要进行cpu切换,也就是会发生进程的切换.切换涉及到清空寄存器,缓存数据.然后重新加载新的thread所需数据.当一个线程被挂起时,加入到阻塞队列,在一定的时间或条件下,在通过notify(),notifyAll()唤醒回来.在某个资源不可用的时候,就将cpu让出,把当前等待线程切换为阻

AtomicInteger源码分析——基于CAS的乐观锁实

1. 悲观锁与乐观锁 我们都知道,cpu是时分复用的,也就是把cpu的时间片,分配给不同的thread/process轮流执行,时间片与时间片之间,需要进行cpu切换,也就是会发生进程的切换.切换涉及到清空寄存器,缓存数据.然后重新加载新的thread所需数据.当一个线程被挂起时,加入到阻塞队列,在一定的时间或条件下,在通过notify(),notifyAll()唤醒回来.在某个资源不可用的时候,就将cpu让出,把当前等待线程切换为阻塞状态.等到资源(比如一个共享数据)可用了,那么就将线程唤醒,

基于redis的乐观锁

转自:https://www.toutiao.com/i6503412526095532558/?tt_from=weixin&utm_campaign=client_share&timestamp=1514535595&app=news_article&utm_source=weixin&iid=22004594589&utm_medium=toutiao_android&wxshare_count=1 在游戏开发中,我们有时需要实现乐观锁功能,乐

Elasticsearch由浅入深(四)ES并发冲突、悲观锁与乐观锁、_version乐观锁并发

ES并发冲突 举个例子,比如是电商场景下,假设说,我们有个程序,工作的流程是这样子的: 读取商品信息(包含了商品库存) 用户下单购买 更新商品信息(主要是将库存减1) 我们比如咱们的程序就是多线程的,所以可能有多个线程并发的去执行上述的3步骤流程 有一个牙膏,库存100件,现在,同时有两个人都过来读取了牙育的数据,然后下单购买了这管牙膏,此时两个线程并发的服务于两个人,同时在进行商品库存数据的修改 总有一个线程是先到的,假设就是线程A ,此时线程A就会先将牙育的库存设置为99件,然后线程B再次将