elasticsearch并发问题与锁机制

谁践踏了优雅 2022-01-31 08:55 235阅读 0赞

# 并发冲突 #

举个例子，比如在电商的场景下，假设我们有个程序，其工作流程为：

1.读取商品信息（包含库存，以牙膏为例）；

2.用户下单购买;

3.更新商品库存（库存减一）;

如果该程序是多线程的，那么总有一个线程是先得到的，假设我们牙膏库存一开始有100件，此时线程A先得到线程将牙膏的库存设置为99件，然后线程B再将牙膏设置为99件，这个时候就已经错了。

上面所述问题就是ES中的并发冲突问题，会导致数据不准确。

![a0c7a296b8583bbf466839ced35d6eeb.png][]

# 并发解决方案 #

在ES中如何解决这类并发冲突问题？

——通过\_version版本号的方式进行**乐观锁**并发控制

在es内部第次一创建document的时候，它的\_version默认会是1，之后进行的删除和修改的操作\_version都会增加1。可以看到删除一个document之后，再进行同一个id的document添加操作，版本号是加1而不是初始化为1，从而可以说明document并不是正真地被物理删除，它的一些版本号信息一样会存在，而是会在某个时刻一起被清除。

在es后台，有很多类似于replica同步的请求，这些请求都是异步多线程的，对于多个修改请求是乱序的，因此会使用\_version乐观锁来控制这种并发的请求处理。当后续的修改请求先到达，对应修改成功之后\_version会加1，然后检测到之前的修改到达会直接丢弃掉该请求；而当后续的修改请求按照正常顺序到达则会正常修改然后\_version在前一次修改后的基础上加1（此时\_version可能就是3，会基于之前修改后的状态）。

es提供了一个外部版本号的乐观控制方案来替代内部的\_version。例如：

?version=1&version_type=external

和内在的\_version的区别在于。对于内在\_version=1，只有在后续请求满足?\_version=1的时候才能够更新成功；对于外部\_version=1，只有在后续请求满足?\_version>1才能够修改成功，即必须大于对应的版本才可以进行修改。

replica同步图示如下图：

![0533beaad5317a8de659067414112d55.png][]

# 说明 #

乐观锁和悲观锁都是指对待并发控制的两种思想，共享锁（S锁，也叫读锁），排他锁（X锁，又称写锁），行锁，表锁，全局锁，文档锁等是具体的锁的实现，且都属于悲观锁，乐观锁没有锁。

# 乐观锁 #

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write\_condition机制的其实都是提供的乐观锁。

在ES中乐观锁主要通过版本号等数据来进行判定该数据是否有被修改过，如果发现版本version与自己不相同，那就说明数据是已经被修改过的，那么它会重新去es中读取最新的数据版本，然后再进行数据上的操作。

## 测试 ##

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

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

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

GET test_index/test_type/7
    
    
    返回：
    
    {
    
      "_index": "test_index",
    
      "_type": "test_type",
    
      "_id": "7",
    
      "_version": 1,
    
      "found": true,
    
      "_source": {
    
        "test_field": "test test"
    
      }
    
    }

（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
    
    }

# 悲观锁 #

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，上锁之后就只有一个线程可以操作这条数据了，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

# 乐观锁和悲观锁对比 #

## 悲观锁 ##

优点：方便，直接加锁，对应用程序来说比较透明，不需要额外的操作；

缺点：并发能力低，同一时间只能有一条线程操作数据;

## 乐观锁 ##

优点：并发能力高，不给数据加锁，可大量线程并发操作;

缺点：麻烦，每次更新的时候，都要先比对版本号，然后可能需要重新加载数据，再次修改，再次更改……这个过程可能需要重复多次；

![213570cbee4957f2b7f7a36d704be47e.png][]

[a0c7a296b8583bbf466839ced35d6eeb.png]: http://www.pianshen.com/images/539/a0c7a296b8583bbf466839ced35d6eeb.png
[0533beaad5317a8de659067414112d55.png]: http://www.pianshen.com/images/949/0533beaad5317a8de659067414112d55.png
[213570cbee4957f2b7f7a36d704be47e.png]: http://www.pianshen.com/images/854/213570cbee4957f2b7f7a36d704be47e.png