Elasticsearch是如何保证并发安全的？

一、什么是并发问题

二、悲观锁&&乐观锁

ES采取的是乐观锁机制

三、ES是如何解决并发问题的？

ES是靠内部维护的一个_version版本号字段进行乐观锁的。
比如我们PUT一条document到ES

PUT /test_index/_doc/1
{
  "test_field" : "test test"  
}

返回结果

{
  "_index" : "test_index",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 1,
  "result" : "created",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 0,
  "_primary_term" : 1
}

这里可以看到_version是1，因为是刚created，我们修改一下再来看看

进行修改这条数据，再次看_version字段：

PUT /test_index/_doc/1
{
  "test_field" : "abc 123"  
}

返回结果

{
  "_index" : "test_index",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 2,
  "result" : "updated",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 1,
  "_primary_term" : 1
}

可以看到_version变成2了。

补充个知识点:
我们删除id=1的document，再看_version

DELETE /test_index/_doc/1

返回结果：

{
  "_index" : "test_index",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 3,
  "result" : "deleted",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 2,
  "_primary_term" : 1
}

_version再次+1了，奇怪，删除怎么还+1？ 我们再PUT试试

再次PUT id=1的document

PUT /test_index/_doc/1
{
  "test_field" : "abc 123"  
}

返回结果

{
  "_index" : "test_index",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 4,
  "result" : "created",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 3,
  "_primary_term" : 1
}

神奇的事情发现了，我们delete掉了，再次PUT的时候_version居然是4而不是1，所以这里引入一个知识点：
他不是立即物理删除的，因为他的一些版本号等信息还是保留着的。先删除一条document，再重新创建这条document，其实会在delete version基础之上，再把version号加1

四、实战演示乐观锁

（1）先构造一条数据

PUT /test_index/test_type/3
{
  "test_field" : "test test"
}

（2）新开个浏览器网页，输入Kibana网址，打开两个Kibana客户端，模拟两个客户端，都获取到了同一条数据
GET /test_index/test_type/3

两个客户端都返回

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "3",
  "_version": 1,
  "found": true,
  "_source": {
    "test_field": "test test"
  }
}

（3）其中一个客户端，先更新了一下这条数据同时带上版本号，es中的数据的版本号跟客户端中的数据的版本号是相同的才能修改，否则视为并发冲突。

PUT /test_index/test_type/3?version=1
{
  "test_field" : "test client one"
}

结果

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "3",
  "_version": 2,
  "result": "updated",
  "_shards": {
    "total": 5,
    "successful": 1,
    "failed": 0
  },
  "created": false
}

结果可看到数据变了，此时版本号是2
（4）另一个客户端，尝试基于version=1的数据进行修改，同样带上version=1（模拟并发请求），进行乐观锁的并发控制

PUT /test_index/test_type/3?version=1
{
  "test_field" : "test client two"
}

结果：

{
  "error": {
    "root_cause": [
      {
        "type": "version_conflict_engine_exception",
        "reason": "[test_type][3]: version conflict, current version [2] is different than the one provided [1]",
        "index_uuid": "ey5OuEyFTHe7QhJUvcLDXQ",
        "shard": "2",
        "index": "test_index"
      }
    ],
    "type": "version_conflict_engine_exception",
    "reason": "[test_type][3]: version conflict, current version [2] is different than the one provided [1]",
    "index_uuid": "ey5OuEyFTHe7QhJUvcLDXQ",
    "shard": "2",
    "index": "test_index"
  },
  "status": 409
}

版本冲突，当前版本是2，要改的1，找不到version=1的数据
（5）在乐观锁成功阻止并发问题之后，尝试正确的完成更新
GET /test_index/test_type/3
返回结果：

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "3",
  "_version": 2,
  "found": true,
  "_source": {
    "test_field": "test client one"
  }
}

基于最新的数据和版本号，去进行修改，修改后，带上最新的版本号（这个步骤可能会需要反复执行好几次才能成功，主要看并发量多少）

PUT /test_index/test_type/3?version=2
{
  "test_field" : "test client two"
}

结果：

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "3",
  "_version": 3,
  "result": "updated",
  "_shards": {
    "total": 5,
    "successful": 1,
    "failed": 0
  },
  "created": false
}

此时version变成了3。