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少了先查找的这一步。在es内部,由es先把原来旧的数据查找出来(得到数据和_version值),partial update的数据更新到这份数据中(带着_version值),然后把原来旧的数据标记为deleted,把新的数据进行替换。由此可以看出,用户是用的partial update,但是在ES内部,仍然是全量替换。但是在替换过程中仍然遵循乐观锁的控制策略。

二、并发情况下partial update实现过程

线程1取得es中的一条数据,此时_version=1,取得这条数据时对他进行partial update,

在线程1取得es中的数据后,线程二也取得该数据,并对该数据进行了修改,并写回了es,此时es中该数据的_version=2,

当线程1把他取的数据进行修改后,重新写回es时,所带的_version =1 ,因为此时es中_version=2,所以修改不成功,es自动将该次partial update fail掉,也就是这种情况下线程一的修改被es自动忽略。es内部会自动执行乐观锁的并发控制策略。

三、当_verion冲突时的办法

线程一写回数据时产生_version冲突,在这种情况下,就可以用以下语法:

1、post /index/type/id/_update?retry_on_conflict=5

retry策略:

(1)
再次获取该document的数据和最新的版本号

(2)
基于最新的版本号再次去更新,如果成功就OK

(3) 如果不成功就再一次执行1和2的步骤,最多执行5次。

2、post /index/type/id/_update?retry_on_conflict=5&version=6

指定版本号,也就是说当这次更新成功后的版本号就是6

原文地址:https://www.cnblogs.com/liuqianli/p/8463662.html

时间: 2024-08-01 19:35:52

25.partial update内置乐观锁并发控制的相关文章

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

一.基于version进行乐观锁并发控制 1).查看一条document GET /test_version/test_version_type/1 { "_index" : "test_version", "_type" : "test_version_type", "_id" : "1", "_version" : 1, "found" : t

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

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

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

基于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

Elasticsearch技术解析与实战(七)Elasticsearch partial update

普通的partial update 1.插入测试数据 PUT /test_index/test_type/10 { "test_field1": "test1", "test_field2": "test2" } 2.更新 POST /test_index/test_type/10/_update { "doc": { "test_field2": "updated test2

Elasticsearch学习笔记(九)partial update

一.什么是partial update? PUT /index/type/id,创建文档&替换文档,就是一样的语法 一般对应到应用程序中,每次的执行流程基本是这样的: (1)应用程序先发起一个get请求,获取到document,展示到前台界面,供用户查看和修改 (2)用户在前台界面修改数据,发送到后台 (3)后台代码,会将用户修改的数据在内存中进行执行,然后封装好修改后的全量数据 (4)然后发送PUT请求,到es中,进行全量替换 (5)es将老的document标记为deleted,然后重新创建

3:基于乐观锁(两种)控制并发: version、external锁

ES是基于乐观锁进行并发控制的. 如果有并发的业务场景,可以直接使用ES内置乐观锁机制. 使用的时候,java程序需要先Get指定的记录,获取到版本号,然后Put的时候,带着该版本号,请求更新. ES只有判断到 该记录的 version = 请求中的version值 时,才能进行更新.如果不相等,则舍弃. 下面演示如何使用乐观锁: 1. 先创建一条记录,此时ES返回信息中会有标识: version=1 PUT  /test_index/test_type/1 { "f1":"

为什么乐观锁效率高于悲观锁?(转,该文章没有给出满意回答)

add by zhj: 这个问题最后没有给出另人满意的答案,我跟提问人有相同的困惑.另外,可参见MySQL事务隔离级别,锁 原文:为什么乐观锁效率高于悲观锁? 标 题: [合集]为什么乐观锁效率高于悲观锁? 发信站: 饮水思源 (2008年05月19日12:29:00 星期一), 站内信件 ☆──────────────────────────────────────☆ magiczhang (梅西,未来之王) 于 2008年05月14日21:13:24 星期三) 提到: 书上都说如果是长事务高

【MySQL】乐观锁和悲观锁

最近学习了一下数据库的悲观锁和乐观锁,根据自己的理解和网上参考资料总结如下: 悲观锁介绍(百科): 悲观锁,正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中, 将数据处于锁定状态.悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了 加锁机制,也无法保证外部系统不会修改数据). 使用场景举例:以MySQL InnoDB为例 商品goods表中有一