ElasticSearch系列——并发机制、悲观锁与乐观锁

---

---

ElasticSearch系列——主目录

---

ElasticSearch的并发冲突问题

---

普通的ES操作流程

• 1.先get document数据，商品信息，显示到网页上，同时在内存中缓存该document的数据
• 2.当网页发生了购买之后，直接基于内存中的数据，进行计算和操作
• 3.将计算后的结果写回ES中

正确的情况下：
我们期望的应该是说，线程A将库存-1 ，设置为99件；
然后线程B接着这个99件，将库存-1 ，变为98件，然后设置到ES中；
最终ES中应该库存是98件才对啊。。。

上面说的这个流程和过程，其实就是ES中的并发冲突问题，会导致数据不准确

• 1.有些场景下，其实是无所谓的，不care这个数据不正确的事情，这种比较少见
• 2.当并发操作ES的线程越多，或者并发请求越多；或者是读取一份数据，供用户查阅和操作的时间越长，因为这段时间里很可能数据在ES中已经被修改了，那么我们拿到的就是旧数据，基于旧数据去操作，后面结果肯定就错了

---

悲观锁与乐观锁两种并发控制方案

---

悲观锁

悲观锁并发控制方案，就是在各种情况下，都上锁
上锁之后，就只有一个线程可以操作这一条数据了
当然，不同的场景下，上的锁不同，如：行级锁，表级锁，读锁，写锁

乐观锁

主要通过线程来判断当前的version是否相同，相同则写入新的数据
并同时更新数据version版本，防止错误更新

---

悲观锁与乐观锁优缺点：

1.悲观锁

• 优点：方便，直接加锁，对应用程序来说，透明，不需要做额外的操作;
• 缺点：并发能力很低，同一时间只能有一条线程操作数据

2.乐观锁

• 优点：并发能力很高，不给数据加锁，大量线程并发操作
• 缺点：麻烦，每次跟新的时候，都要先比对版本号，然后可能需要重新加载数据，再次修改，再写。这个过程,可能要重复好几次

---

Elasticsearch内部如何基于_version、external version进行乐观锁并发控制

---

1 . 认识_version

写入数据：

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

再写入一次：

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

结果显示

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

2 . 实战演练基于_version进行乐观锁并发控制

（1）先构造一条数据出来

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

（2）模拟两个客户端，都获取到了同一条数据

GET test_index/test_type/7

（3）其中一个客户端，先更新了一下这个数据

同时带上数据的版本号，确保说，es中的数据的版本号，跟客户端中的数据的版本号是相同的，才能修改

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

结果显示

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

（4）另外一个客户端，尝试基于version=1的数据去进行修改，同样带上version版本号，进行乐观锁的并发控制

PUT /test_index/test_type/7?version=1 
{
  "test_field": "test client 2"
}

结果显示

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

（5）在乐观锁成功阻止并发问题之后，尝试正确的完成更新

GET /test_index/test_type/7

结果显示

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

基于最新的数据和版本号，去进行修改，修改后，带上最新的版本号，可能这个步骤会需要反复执行好几次，才能成功，特别是在多线程并发更新同一条数据很频繁的情况下

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

结果显示

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

---

3 . 实战演练基于external version进行乐观锁并发控制

---

external version

es提供了一个feature，就是说，你可以不用它提供的内部_version版本号来进行并发控制，可以基于你自己维护的一个版本号来进行并发控制。

举个列子，假如你的数据在mysql里也有一份，然后你的应用系统本身就维护了一个版本号，无论是什么自己生成的或程序控制的。这个时候，你进行乐观锁并发控制的时候，可能并不是想要用es内部的_version来进行控制，而是用你自己维护的那个version来进行控制。

?version=1   基于_version
?version=1&version_type=external   基于external version

_version与version_type=external唯一的区别在于：

• _version，只有当你提供的version与es中的_version一模一样的时候，才可以进行修改，只要不一样，就报错

• 当version_type=external的时候，只有当你提供的version比es中的_version大的时候，才能完成修改

es，_version=1，    ?version=1，才能更新成功

es，_version=1，    ?version>1&version_type=external，才能成功，
比如说：?version=2&version_type=external

（1）先构造一条数据

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

结果显示

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "8",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": true
}

（2）模拟两个客户端同时查询到这条数据

GET /test_index/test_type/8

结果显示

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

（3）第一个客户端先进行修改，此时客户端程序是在自己的数据库中获取到了这条数据的最新版本号，比如说是2

PUT /test_index/test_type/8?version=2&version_type=external
{
  "test_field": "test client 1"
}

结果显示

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

（4）模拟第二个客户端，同时拿到了自己数据库中维护的那个版本号，也是2，同时基于version=2发起了修改

PUT /test_index/test_type/8?version=2&version_type=external
{
  "test_field": "test client 2"
}

结果显示

{
  "error": {
    "root_cause": [
      {
        "type": "version_conflict_engine_exception",
        "reason": "[test_type][8]: version conflict, current version [2] is higher or equal to the one provided [2]",
        "index_uuid": "6m0G7yx7R1KECWWGnfH1sw",
        "shard": "1",
        "index": "test_index"
      }
    ],
    "type": "version_conflict_engine_exception",
    "reason": "[test_type][8]: version conflict, current version [2] is higher or equal to the one provided [2]",
    "index_uuid": "6m0G7yx7R1KECWWGnfH1sw",
    "shard": "1",
    "index": "test_index"
  },
  "status": 409
}

（5）在并发控制成功后，重新基于最新的版本号发起更新

GET /test_index/test_type/8

结果显示

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

PUT /test_index/test_type/8?version=3&version_type=external
{
  "test_field": "test client 2"
}

结果显示

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