举个例子，比如是电商场景下，下单流程为：
1 读取商品信息（包含商品库存）
2 用户下单购买商品
3 更新商品信息（主要是将库存减1）
可能是多个线程并发的去执行上面的步骤
有一款牙膏，库存为100件，同时有两个人读取牙膏信息，下单购买，此时两个线程并发执行，同时在进行对商品库存数据的修改。
总有一个线程先到，假设线程A将牙膏的库存设置为99件，然后线程B再次将牙膏的库存设置为99件，结果是错误的。
对于普通的ES操作流程就是
1先获得document商品信息，显示到网页上，同时在内存中缓存document数据
2当数据发生变化时，直接基于内存中的数据，进行计算和操作
3最后将计算后的结果写回ES中
正常的情况下，我们期望的是应该是线程A将库存-1，库存为99件，然后线程B再将99件商品库存-1，变为98件，然后设置到ES中，最终ES的库存应该是98件
这就是ES的并发冲突问题导致数据不准确。
当并发操作ES的线程越多，或者并发请求越多，或者查询和操作的时间越长，在这段时间中都有可能导致ES已经被修改，我们拿到的数据已经是旧数据，基于旧数据操作，结果必然是错的
如果在某些场景下，不关心数据的准确性，只是简单的将数据写入ES中，那么有没有并发冲突问题是无所谓的
2、深度图解剖析悲观锁与乐观锁两种并发控制方案 悲观锁并发控制方案常见于关系型数据库，比如MySQL
这只是思路并非说MySQL中悲观锁就是这样一模一样实现的
线程A读取ES的牙膏数据时进行加锁，用户A读取的数据100件
此时线程B无法读取数据
用户A下单，线程A将库存-1=99写回ES 锁被释放
此时线程B可以读取到数据并进行加锁，用户B读取的数据时99件
用户B下单，线程B将库存-1=98写回ES，并释放锁
对于关系型数据库加锁，同一时刻只能有一个线程操作数据，当然根据不同的场景，锁的细粒度是不同的，比如行锁、表锁、页锁、读锁、写锁等等
乐观锁并发控制方案对于ES使用的是乐观锁，加入版本号机制
写的时候，会判断当前数据的版本号与es中数据的版本号是否一致
假如线程A先修改数据，判断当前version与es中的version一致，数据修改成功version修改为2
此时线程B修改数据，发现当前数据的版本号version=1与es中数据的版本号version=2不一致，数据修改失败
1 悲观锁的优点：操作方便，直接加锁不需要做额外的操作
缺点：并发能力低，同一时间只能有一个线程操作数据
2乐观锁的优点：并发能力高，不需要加锁，大量数据并发操作
缺点：操作麻烦，每次操作都要更新版本号，并发高的情况下很容易出现操作失败，需要重新加载数据，再次修改。
3、图解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
全量替换
PUT /test_index/test_type/6
{
"test_field": "test test2"
}
响应结果
{
"_index": "test_index",
"_type": "test_type",
"_id": "6",
"_version": 2,
"result": "updated",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": false
}
删除
DELETE /test_index/test_type/6
响应结果
{
"found": true,
"_index": "test_index",
"_type": "test_type",
"_id": "6",
"_version": 3,
"result": "deleted",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
}
}
查询 已经查询不到了
GET /test_index/test_type/6
响应结果
{
"_index": "test_index",
"_type": "test_type",
"_id": "6",
"found": false
}
再次创建
PUT /test_index/test_type/6
{
"test_field": "test test"
}
响应结果
{
"_index": "test_index",
"_type": "test_type",
"_id": "6",
"_version": 4,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}
我们会发现，在删除一个document之后，可以从一个侧面证明，它不是立即物理删除掉的，因为它的一些版本号等信息还是保留着的。先删除一条document，再重新创建这条document，其实会在delete version基础之上，再把version号加1
注：有可能会出现删除数据时立刻物理删除，如果出现可以多试几次。
1创建一个document，filed = test1
2修改
对于ES的操作请求，类似于replica同步请求，都是多线程异步的，多个修改请求之间是乱序的，可能后修改的先到，先修改的后到。
es的乐观锁并发控制机制保证先到的修改能够修改成功，后到的修改就修改不成功
所以es的多线程异步并发修改是基于_version版本号进行乐观锁并发控制的
在后修改操作先到时，那么filed=test3， version = 2
先修改操作后到时，会比较version的版本号，如果不相等，那么此次的修改操作就废弃了
这样结果就保证为一个正确的结果filed = test3
