Elasticsearch文档版本冲突原理与解决

一般我们在更新文档时，主要的操作流程时：读取文档->修改->提交保存。数据中心等保存的都是最新一次提交的内容。

大部分时候，这都没有什么问题。但是如果两个或更多的请求同时修改一个文档时，非常容易产生冲突，因为上述的流程无法保证原子性，也不可能保证。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gvf49ni4-1585230464114)(https://www.elastic.co/guide/en/elasticsearch/guide/current/images/elas_0301.png#pic_center =300x400)]
冲突解决常用的两种策略：

1. 悲观锁并发策略
   在关系性数据库中，通过阻塞并排队的方式，来避免发生冲突，例如在读取数据行时阻塞，来保证正在修改行数据的请求完成正常操作后，以读取到最新的数据。这种方式的前提假设是数据冲突更有可能发生。
2. 乐观锁并发策略
   Elasticsearch中采用的是乐观锁的并发策略，这种方式的前期假设是数据冲突一般不会发生，从而避免阻塞数据请求。然而，在读和写之间，如果数据发生改变，更新就失败了，然后由程序决定如果进行后续的处理。

Elasticsearch是分布式的，文档的创建/变更等都会同步到其他节点。由于其异步性和并发的特点，这些同步请求都是并行的，因此并不能保证数据的是按照修改顺序依次到达的。Elasticsearch保证了一个老版本的数据永远无法重写或覆盖更新版本的数据。

在 index get 和 delete请求中，都存在一个 _version 字段。数据的变更均会导致_version 的值增大。Elasticsearch通过该字段来保证小于该值的数据会被忽略掉。

通过数字版本的方式也可以避免ABA的数据问题，即数据A修改为B而后又修改为A，对于应用端来说，数据是没有任何变化的

创建文档：

PUT /website/blog/1/_create
{
  "title": "My first blog entry",
  "text":  "Just trying this out..."
}

获取文档：

GET /website/blog