ES并发冲突的问题

当并发操作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次