ElasticSearch教程——partial update（更新文档）实现原理及并发控制

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/gwd1154978352/article/details/82856427

ElasticSearch汇总请查看：ElasticSearch教程——汇总篇

语法

partial update语法如下

post /index/type/id/_update 
{
   "doc": {
      "要修改的少数几个field即可，不需要全量的数据"："对应field的数据"
   }
}

创建文档&替换文档语法如下

PUT /index/type/id
{
"所有field":"对应field的值"
}

内部原理

看起来，好像partial update比较方便，每次就传递少数几个发生修改的field即可，不需要将全量的document数据发送过去，那他是指上的内部原理又是什么呢？

1. 其实es内部对partial update的实际执行和传统的全量替换方式是几乎一样的，其步骤如下
2. 内部先获取到对应的document；
3. 将传递过来的field更新到document的json中(这一步实质上也是一样的);
4. 将老的document标记为deleted（到一定时候才会物理删除）;
5. 将修改后的新的document创建出来

partial update相比较全量替换的优点

1. 所有从查询、修改和写回操作都是发生在es中的一个shard内部（一瞬间就完成，可能基本上是毫秒级别的），避免了所有的网络数据传输的开销，大大提升了性能;
2. 减少了查询和修改中的时间间隔，可以有效减少并发冲突的情况;

并发控制

partial update内部会自动执行我们之前所说的乐观锁的并发控制策略，具体可以参考ElasticSearch教程——并发问题与锁机制

即修改数据之前会比对版本，如果版本不对会更新到最新的数据，然后再进行修改，这个过程可能需要周而复始才能成功。

retry策略

就像ElasticSearch教程——并发问题与锁机制这篇博客在乐观锁的缺点中所说的一样，在尝试获取版本并进行数据更新的过程中，这个过程可能需要多次重复执行，然而在某些时候我们又需要对这个重复执行的次数做个限制，那应该怎么做呢？

这边的retry_on_conflict就是我们设置的修改失败后的重复次数

post /index/type/id/_update?retry_on_conflict=5

当然啦，如果倔强的你必须规定是某个版本下的修改失败的最大重复次数还可以这么写

post /index/type/id/_update?retry_on_conflict=5&version=6