Elastic-Search updateByQuery conflicts

前言

ES嵌套索引的增删改其实是不安全的，所有的数据库db系统都会存在并发问题，像关系型数据库MySQL，Oracle，SQL Server，默认采用的是悲观锁，而在Elastic-Search中采用的乐观锁。

下面先熟悉下什么是乐观锁和悲观锁：

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。

ES的乐观锁是基于CAS(Compare And Set)原理，在更新文档时，总是会先获取待更新文档的快照，然后对快照执行更新，version默认加1，更新完落库，若落库的时候发现更新后的快照version <= 库中对应文档的version，则产生冲突，更新失败。很好理解，当多线程操作同一文档时，冲突是很容易发生的。

解决冲突的思路

1.采用分布式锁

基于redis或zookeeper都可实现分布式锁，其实是悲观锁实现，即若多个线程同时更新文档，更新文档前，线程必须先竞争获取到唯一的一把锁，获取锁之后才能进行更新。优点：可最大限度避免文档更新的冲突

2.基于乐观锁重试机制

顾名思义，若version发生冲突，则不断进行重试，当然必须设置最大重试次数。优点：在读多写少的情况下，可最大程度保留ES性能，笔者在项目中便是采用此种方式对ES文档做增量更新

参考

https://blog.csdn.net/u010454030/article/details/60969509