ElasticSearch【分布式锁】

一、简介

       ES在多线程并发访问修改情况下会用到锁机制。大致分为乐观锁和悲观锁。

二、乐观锁

       通过_version来记录文档版本。在文档创建时会有一个初始version，默认为1.对文档修改或者删除时，version会递增，也可以指定。只有当版本号大鱼当前版本时，才会修改或者删除成功，否则失败。当并发请求时，先修改成功的，version会增加，这个时候，其他请求就会因为version不匹配从而修改失败。     

由于segment时不能被修改的，所以当对一个文档执行DELETE之后，在插入相同id的文档，version版本不会是0，而是在DELETE操作的version上递增

      外部版本号和内部版本号区别

      对于内在_version=1,只有在后续请求满足?_version=1的时候才能更新成功；对于外部_version=1,只有在后续请求满足?_version>1才能修改成功。   

es提供了一个外部版本号的乐观控制方案来替代内部的_version。
？version=1&version_type=external

三、悲观锁

       悲观锁类似于数据库中的锁。当线程1在修改或删除doc时，会对数据上锁，这个时候其它线程不能对数据进行操作的。这种方式保证了只有一个线程在同时操作数据。这种方式的缺点是对系统性能有影响，会降低整个系统并发能力，因为其他线程要等待。

       悲观锁主要有以下几种：全局锁、文档锁

       3.1、全局锁

                对整个index上锁，类似数据库的表锁。

                当对文档进行操作时，会对整个index。
              

##上锁
PUT /fs/lock/global/_create
{}
##释放锁
DELETE /fs/lock/global

       3.2、文档锁

                在文档级别上锁，类似数据库的行锁。

                create上锁

PUT /fs/lock/_bulk
{ "create": { "_id": 1}} 
{ "process_id": 123    } 
{ "create": { "_id": 2}}
{ "process_id": 123    }

               update上锁，需要用脚本。

POST /fs/lock/1/_update
{
  "upsert": { "process_id": 123 },
  "script": "if ( ctx._source.process_id != process_id )
  { assert false }; ctx.op = 'noop';"
  "params": {
    "process_id": 123
  }
}

              如果update文档不存在，则走上面的create。如果文档存在，脚本会查看文档中的process_id是否和要修改的process_id匹配，如果匹配不会执行update，但是会返回为成功。如果不匹配即上锁失败。