当并发操作ES的线程越多,或者并发请求越多,或者是读取一份数据,供用户查询和操作的,时间越长,因为这段时间里很可能
数据在ES已经被修改了,那么我们拿到的就是旧的数据,基于旧数据操作,那么后续肯定会出问题

所以我们有悲观锁和乐观锁俩种并发控制方案
悲观锁并发控制方案
常见于关系型数据库中,比如mysql
悲观锁并发控制方案,就是在各种情况下,都上锁,上锁之后,就只有一个线程可以操作这一条数据了,当然,不同情况下
上锁不同(行级锁,表级锁,读锁,写锁)

乐观锁控制方案
假设有线程AB
线程B去判断,当前数据的版本号,version=1,与es中的数据的版本号,version=2,是否相同,明显是不同的,版本号不同,
说明数据已经被其他人修改过了,此时用户B不会用99去更新,而是重新去es中读取最新的数据版本,99件,再次减一,变为
98件,再次执行一下操作就可以

悲观锁和乐观锁
1. 悲观锁的优点:方便,直接加锁,对应用程序来说,透明,不需要做额外的操作
缺点:并发能力很低,同一时间只能有一条线程操作数据

2. 乐观锁的优点是:并发能力很高,不给数据加锁,大量线程并发操作,
缺点:麻烦,每次更新的时候都要先比对版本号,然后可能需要更新加载数据,再次修改,再写,这个过程可能要重复好几次

 

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

在删除一个document后,他不是立即物理删除掉的,因为它的一些版本号等信息还是保留的,先删除一条document,再重新创建
这条document,其实会在delete version基础之上,再把version+1

 

partial update内部会自动执行我们之前所说的乐观锁的并发控制政策
retry策略
1. 再次获取document的数据和最新版本号
2. 基于最新版本号再次去更新,如果成功就ok
3. 如果失败了,重复1和2俩个步奏,最多重复的次数可以通过retry那个参数的值指定,比如5次

 

转载于:https://www.cnblogs.com/gouhaiping/p/11887359.html