【ElasticSearch】并发冲突问题与partial update

绝地灬酷狼 2022-12-25 00:58 119阅读 0赞

# es并发冲突问题： #

假设两个线程，读取商品信息库存100，然后分别下单，这时库存最新应是98，但是两个线程并发更新库存，可能同时读取的库存100，线程A下单减一，剩99，线程B下单剩99，这个结果是不对的。  
如果解决呢？  
加锁。  
悲观锁：线程A读取库存的时候加锁，然后下单扣库存，完事儿再线程B读库存下单  
乐观锁：乐观锁不加锁，读取库存时标注版本号为1，线程A处理完库存为99后，线程B拿着99，version=1去更新es比对版本发现不匹配会重新读取库存，此时库存为99，线程B在99-1=98件，写回es。

优缺点比较：  
悲观：方便，直接加锁，对应用程序透明，不需额外操作，缺点，并发能力很低  
乐观：并发能力高，不给数据加锁，大量线程并发操作，缺点，麻烦，每次更新时，都要先比对版本号，可能重新加载数据，再次修改，再写，这个过程可能要重复好多次。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hvbmd3ZWkxNTczMjYyMzM2NA_size_16_color_FFFFFF_t_70]  
可能后修改的先到，先修改的后到，这样导致修改后到的结果不对？  
es内部的多线程异步并发修改时，是基于自己的\_version版本号进行乐观锁并发控制的，es内部，对先修改的后到的，会舍弃；先修改先到，后修改后到的正常比对版本，正常修改数据。

# partial update？ #

需要修改哪个字段就传哪个字段，操作方便。  
Post /index/type/id\_update  
\{  
“doc”:\{  
“要修改的field”  
\}  
\}

es内部对patial update的实际执行，跟传统的鄂全量替换方式，几乎一样。  
1、内部先获取document  
2、将传过来的鄂field更新到docum的json中  
3、将老的document标记为deleted  
4、将修改后的新的docum创建出来

partial update比全量替换的优点：  
1、所有的查询、修改和写回操作，都发生在es中的一个shard内部，避免了所有的网络数据传输的开销（减少两次网络请求），大大提升了性能  
2、减少了查询和修改中的时间间隔，可以有效减少并发冲突

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hvbmd3ZWkxNTczMjYyMzM2NA_size_16_color_FFFFFF_t_70]: /images/20221120/41919aaa979d493ea30558af1723ec2b.png