1、Elasticsearch并发冲突问题
举例：
在电商场景下，流程一般为：
1.读取商品信息（包含商品库存）-->2.用户下单购买-->3.更新商品信息（这里主要是商品库存更新）
如图所示：
并发冲突问题剖析
2、悲观锁与乐观锁两种并发控制方案
（1）悲观锁
- 悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
- 一段执行逻辑加上悲观锁,不同线程同时执行时,只能有一个线程执行,其他的线程在入口处等待,直到锁被释放.
优点：便捷，直接加锁，对应用程序来说，透明，不需要额外操作。
缺点：并发能力很低，同一时间只能有一条线程操作数据。
（2）乐观锁.
- 乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
- 一段执行逻辑加上乐观锁,不同线程同时执行时,可以同时进入执行,在最后更新数据的时候要检查这些数据是否被其他线程修改了(版本和执行初是否相同),没有修改则进行更新,否则放弃本次操作。
-
version方式:
一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
优点：并发能力很高，不给数据加锁，大量线程并发操作。
缺点：麻烦，每次更新的时候都要先对比版本号，然后可能需要重新加载数据，再次修改，再写，这个过程可能要重复好几次。
悲观锁与乐观锁两种并发控制方案
悲观锁和乐观锁参考：https://www.cnblogs.com/ldy-blogs/p/9772076.html
