Elasticsearch-并发冲突处理机制

详解并发冲突

在电商场景下，工作流程为：

1. 读取商品信息，包括库存数量
2. 用户下单购买
3. 更新商品信息，将库存数减一
   如果是多线程操作，就可能有多个线程并发的去执行上述的3步骤流程，假如此时有两个人都来读取商
   品数据，两个线程并发的服务于两个人，同时在进行商品库存数据的修改。假设库存为100件 正确的情
   况：线程A将库存-1，设置为99件，线程B接着读取99件，再-1，变为98件。如果A,B线程都读取的为
   100件，A处理完之后修改为99件，B处理完之后再次修改为99件，此时结果就出错了

解决方案

• 悲观锁
  顾名思义，就是很悲观，每次去拿数据的时候都认为被人会修改，所以每次拿数据的时候都会加锁，以
  防别人修改，直到操作完成后，才会被别人执行。常见的关系型数据库，就用到了很多这样的机制，如
  行锁，表锁，写锁，都是在操作之前加锁。
  悲观锁的优点：方便，直接加锁，对外透明，不需要额外的操作。
  悲观锁的缺点：并发能力低，同一时间只能有一个操作。
  
• 乐观锁
  乐观锁不加锁，每个线程都可以任意操作。比如每条文档中有一个version字段，新建文档后为1，修改一次累加，线程A,B同时读取到数据，version=1，A处理完之后库存为99，在写入es的时候会跟es中的版本号比较，都是1，则写入成功，version=2，B处理完之后也为99，存入es时与es中的数据的版本号version=2相比，明显不同，此时不会用99去更新，而是重新读取最新的数据，再减一，变为98，执行上述操作写入
  

Elasticsearch的乐观锁

Elasticsearch的后台都是多线程异步的，多个请求之间是乱序的，可能后修改的先到，先修改的后到
Elasticsearch的多线程异步并发修改是基于自己的_version版本号进行乐观锁并发控制的。
在后修改的先到时，比较版本号,版本号相同修改可以成功，而当先修改的后到时，也会比较一下
_version版本号，如果不相等就再次读取新的数据修改。这样结果会就会保存为一个正确状态
删除操作也会对这条数据的版本号加1
在删除一个document之后，可以从一个侧面证明，它不是立即物理删除掉的，因为它的一些版本号等
信息还是保留着的。先删除一条document，再重新创建这条document，其实会在delete version基础
之上，再把version号加1

es的乐观锁并发控制示例

• 先新建一条数据

PUT /test_index/_doc/4
{
   
   
"test_field": "test"
}

模拟两个客户端，都获取到了同一条数据

GET /test_index/_doc/4