ElasticSearch最佳入门实践（十七）剖析Elasticsearch并发冲突问题以及控制方案

• 场景

电商场景下，有个程序的工作流程
1、读取商品信息（商品信息中包含库存）
2、用户下单购买
3、更新商品信息（更新库存信息）
电商场景下，多个用户同时下单购买同一商品，多线程并发修改库存。

• 操作

现在有多个用户同时操作，多个线程同时并发去执行上面的3个步骤
用户A获取到库存100件
用户B获取到库存100件
然后两个用户同时提交订单，但是总有一个线程是先到的，如果线程A先到，就会先将库存 -1 设置为99件。然后线程B再次将库存设置为 99 件，此时结果已经错了。

• 我们期待的结果

线程A先将库存设置为99件，线程B在99件的基础上 -1 设置为 98 件 

• 并发控制解决方案

1.悲观锁

常见于关系型数据库，比如mysql
商品库存100件。
当用户A读取该商品数据的时候，会同时给数据库这一行加锁，而当用户B也读取该商品数据的时候，这个时候会被卡出处于等待状态。
只有当用户A购买商品后 库存-1 ，才会释放锁。此时用户B突然就可以动弹了，这个时候获取到的商品库存为 99 件，当用户B购买商品后，库存变为 98。

悲观锁的控制方案就是在任何情况下，都上锁，上锁之后只有一个线程可以操作这条数据了。
当然在不同的场景下上的锁也不同，例如：表级锁、行级锁、读锁、写锁。

2.乐观锁

商品库存100件。
乐观锁状态下是不加锁的，每个线程都可以任意操作。
此时库存为 100
当用户A购买商品后 库存-1 ，此时商品库存为 99。这个时候用户B也提交了订单，只是用户B线程携带的数据库存为100件。乐观锁状态下，用户B会去校验 ES 中的的这条数据版本号和自身的是否一致，如果不一致，则不会提交，会重新去 ES 中获取最新的数据 99 件，再次减一，变为 98。再执行上述流程就可以写入。

• 总结

悲观锁
优点：方便，直接加锁，不需任何操作。
缺点：并发能力低，同一时间只有一个线程可以操作数据

乐观锁
优点：并发能力很高，不用给数据加锁，大量线程并发操作。
缺点：麻烦，每次操作都要校验版本号，这种情况下可能需要重新加载数据，再写，再次修改，可能会持续好几个过程