1、图解Elasticsearch内部如何基于_version进行乐观锁并发控制

（1）_version元数据

  1. PUT /test_index/_doc/6
  2. {
  3.   "test_field": "test test"
  4. }
  6. {
  7.   "_index": "test_index",
  8.   "_type": "test_type",
  9.   "_id": "6",
  10.   "_version": 1,
  11.   "result": "created",
  12.   "_shards": {
  13.     "total": 2,
  14.     "successful": 1,
  15.     "failed": 0
  16.   },
  17.   "created": true
  18. }

第一次创建一个document的时候，它的 _version 内部版本号就是1；以后，每次对这个document执行修改或者删除操作，都会对这个 _version 版本号自动加1；哪怕是删除，也会对这条数据的版本号加1

{
  "found": true,
  "_index": "test_index",
  "_type": "test_type",
  "_id": "6",
  "_version": 4,
  "result": "deleted",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  }
}

我们会发现，在删除一个document之后，可以从一个侧面证明，它不是立即物理删除掉的，因为它的一些版本号等信息还是保留着的。先删除一条document，再重新创建这条document，其实会在delete version基础之上，再把version号加1
image
注：
旧版本的elasticsearch是用version来解决并发问题，采用乐观锁的方式，比较更新时的version是否相同来决定能不能更新
在新版本es再使用version就会报上述问题，而新版本用的是 _seq_no 和_primary_term两个字段来代替version处理并发问题，在查询文档时，这两个字段会返回。