Elastic Search写入更新的并发原因，方案，处理以及优化

一. 情景（列子）

一个报名系统:

1. 读取报名信息
2. 用户点击报名
3. 更新报名

程序上面来讲，在多线程的情况下，每个线程都去执行上面的报名的三个步骤，总有一个线程是先到的，假设是线程A,此时线程A就会先将本来报名名额数量100设置成99，然后线程B紧接着到达，这时产生了并发，他还没等线程A先将数量设置成99自己已经先取出原来的名额100，这个时候减去1后还是99，将数量设置成99了，但是正常的逻辑是98才对。这个是并发产生的原因。

二.方案

2种方案：悲观所和乐观锁

1. 悲观锁类似mysql数据库中的锁表，当A线程读取报名信息（名额）的时候，进行（整张报名表锁。或者对名额进行行锁）这样，其他线程遇到锁后都不会执行查新，更新，插入。等到，A线程完成减1更新操作后，表进行解锁。这样另外一个线程可以继续执行上面的过程。
2. 乐观锁类似Es 使用数据的版本号来进行控制。当A线程进入报名流程时，报完后，他的数量减1，这个时候B线程ke能比他快减1且比他更快的更新了报名名额为99，此时。A在更新时发现他的版本号已经和库里面的版本号不一致了，呢么他再次取出库里面的数量99再减一，如果此时C线程又比他快，呢么他再次发现版本号回不一致，再次从库汇总取出数量99.减一再次进去。依次类推直到他比被人快，这样虽然会重复好多步骤但是不给数据枷锁，并发能力比较高，悲观锁相比乐观锁的话就并发能力低了

三.处理（举例）

1. 构建一条数据

PUT /testindex/testtype/11
{
   
	"fields1":"并发处理"
}

2. 假设2个线程都get到了这条数据

GET /testindex/testtype/11
//显示结果如下:
{
   
  "_index": "testindex&