es 乐观锁的控制机制

1、图解Elasticsearch内部如何基于_version进行乐观锁并发控制

(1)_version元数据

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

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

第一次创建一个document的时候,它的_version内部版本号就是1;以后,每次对这个document执行修改或者删除操作,都会对这个_version版本号自动加1;哪怕是删除,也会对这条数据的版本号加1

{
"found": true,
"_index": "test_index",
"_type": "test_type",
"_id": "6",
"_version": 4,
"result": "deleted",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
}
}

我们会发现,在删除一个document之后,可以从一个侧面证明,它不是立即物理删除掉的,因为它的一些版本号等信息还是保留着的。先删除一条document,再重新创建这条document,其实会在delete version基础之上,再把version号加1

原文地址:https://www.cnblogs.com/siye1989/p/11562197.html

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

es 乐观锁的控制机制的相关文章

乐观锁之版本号机制和CAS

---恢复内容开始--- 乐观锁:每次去拿数据的时候,都认为别人不会修改,不会加锁,但在更新的时候会去判断一下,此期间别人有没有更新数据,版本号机制和CAS算法就用到乐观锁,参考了https://blog.csdn.net/u011381576/article/details/79922538: 举一个版本号的例子, 数据表中除了数据还有一个version字段,更新数据时version字段会加一, 假设线程A在读取数据和version(version = 1)的期间,有另一个线程B也读取了ver

[数据库事务与锁]详解八:底理解数据库事务乐观锁的一种实现方式——CAS

注明: 本文转载自http://www.hollischuang.com/archives/1537 在深入理解乐观锁与悲观锁一文中我们介绍过锁.本文在这篇文章的基础上,深入分析一下乐观锁的实现机制,介绍什么是CAS.CAS的应用以及CAS存在的问题等. 线程安全 众所周知,Java是多线程的.但是,Java对多线程的支持其实是一把双刃剑.一旦涉及到多个线程操作共享资源的情况时,处理不好就可能产生线程安全问题.线程安全性可能是非常复杂的,在没有充足的同步的情况下,多个线程中的操作执行顺序是不可预

HIbernate乐观锁与悲观锁

悲观锁 从加载对象就开始锁定.修改过程中一直是锁.直到commit()提交后再解锁.只需要在加载对象时加上(LockOptions.UPGRADE)即可,如下所示 Info info=session.load(Info.class,"p003",LockOptions.UPGRADE); 这样带来的问题就是,当访问量大的时候就会造成排队等待的后果. 乐观锁 相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制.悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性.但随之而

公平锁,非公平锁,乐观锁,悲观锁

公平锁/非公平锁(多线程执行顺序的维度) 概念理解 公平锁:加锁前先查看是否有排队等待的线程,有的话优先处理排在前面的线程,先来先得. 非公平所:线程加锁时直接尝试获取锁,获取不到就自动到队尾等待. 例子 ReentrantLock 同时支持两种锁 //创建一个非公平锁,默认是非公平锁 Lock nonFairLock= new ReentrantLock(); Lock nonFairLock= new ReentrantLock(false); //创建一个公平锁,构造传参true Lock

【多线程】公平锁/非公平锁、乐观锁/悲观锁

公平锁/非公平锁(多线程执行顺序的维度) 概念理解 公平锁:加锁前先查看是否有排队等待的线程,有的话优先处理排在前面的线程,先来先得. 非公平所:线程加锁时直接尝试获取锁,获取不到就自动到队尾等待. 例子 ReentrantLock 同时支持两种锁 //创建一个非公平锁,默认是非公平锁 Lock nonFairLock= new ReentrantLock(); Lock nonFairLock= new ReentrantLock(false); //创建一个公平锁,构造传参true Lock

面试必问系列:谈谈乐观锁与悲观锁!

前言 乐观锁和悲观锁问题,是出现频率比较高的面试题.本文将由浅入深,逐步介绍它们的基本概念.实现方式(含实例).适用场景,以及可能遇到的面试官追问,希望能够帮助你打动面试官. 目录 一.基本概念二.实现方式(含实例)三.优缺点和适用场景四.面试官追问:乐观锁加锁吗?五.面试官追问:CAS有哪些缺点?六.总结 一.基本概念 乐观锁和悲观锁是两种思想,用于解决并发场景下的数据竞争问题. 乐观锁:乐观锁在操作数据时非常乐观,认为别人不会同时修改数据.因此乐观锁不会上锁,只是在执行更新的时候判断一下在此

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

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

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

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

mysql中的锁机制之悲观锁和乐观锁

1.悲观锁? 悲观锁顾名思义就是很悲观,悲观锁认为数据随时就有可能会被外界进行修改,所以悲观锁一上来就会把数据给加上锁.悲观锁一般都是依靠关系型数据库提供的锁机制,然而事实上关系型数据库中的行锁,表锁不论是读写锁都是悲观锁. 2.乐观锁? 乐观锁顾名思义,就是很乐观,每次自己操作数据的时候认为没有人会来修改它,所以不会去对数据进行加锁.但是在更新的时候会去判断在此期间数据有没有被修改,需要用户自己去实现乐观锁.乐观锁不会发生并发抢占资源,只有在提交操作的时候检查是否违反数据完整性. 2.1.为什