Elasticsearch在文档更新时默认使用的是乐观锁方案，而Elasticsearch利用文档的一些create限制条件，也能达到悲观锁的效果，我们一起来看一看。
乐观锁与悲观锁 乐观锁ES默认实现乐观锁，所有的数据更新默认使用乐观锁机制。document更新时，必须要带上currenct version，更新时与document的version进行比较，如果相同进行更新操作，不相同表示已经被别的线程更新过了，此时更新失败，并且重新获取新的version再尝试更新。
悲观锁我们举一个这样的例子：Elasticsearch存储文件系统的目录、文件名信息，有多个线程需要对/home/workspace/ReadMe.txt进行追加修改，而且是并发执行的，有先后顺序之分，跟之前的库存更新案例有点不一样，此时单纯使用乐观锁，可能会出现乱序的问题。
这种场景就需要使用悲观锁控制，保证线程的执行顺序，有一个线程在修改，其他的线程只能挂起等待。悲观锁通过/index/lock/实现，只有一个线程能做修改操作，其他线程block掉。
悲观锁有三种，分别对应三种粒度，由粗到细可为分：
全局锁：最粗的锁，直接锁整个索引
document锁：指定id加锁，只锁一条数据，类似于数据库的行锁
共享锁和排他锁：也叫读写锁，针对一条数据分读和写两种操作，一般共享锁允许多个线程对同一条数据进行加锁，排他锁只允许一个线程对数据加锁，并且排他锁和共享锁互斥。
锁的基本操作步骤我们使用锁的基本步骤都是一样的，无论是关系型数据库、Redis/Memcache/Zookeeper分布式锁，还是今天介绍的Elasticsearch实现的锁机制，都有如下三步：
上锁
执行事务方法
解锁
全局锁假定有两个线程，线程1和线程2
线程1上锁命令：
PUT /files/file/global/_create {}files表示索引名称。
file为type，6.3.1一个索引只允许有一个type，选用file作用type名称。
global：即document的id，固定写为global表示全局锁，或者使用专门的索引进行加锁操作。
_create: 强制必须是创建，如果已经存在，那么创建失败，报错。
线程1执行事务方法：更新文件名
POST /files/file/global/_update { "doc": { "name":"ReadMe.txt" } }线程2尝试加锁，失败，此时程序进行重试阶段，直到线程1释放锁
# 请求： PUT /files/file/global/_create {} # 响应： { "error": { "root_cause": [ { "type": "version_conflict_engine_exception", "reason": "[file][global]: version conflict, document already exists (current version [1])", "index_uuid": "_6E1d7BLQmy9-7gJptVp7A", "shard": "2", "index": "files" } ], "type": "version_conflict_engine_exception", "reason": "[file][global]: version conflict, document already exists (current version [1])", "index_uuid": "_6E1d7BLQmy9-7gJptVp7A", "shard": "2", "index": "files" }, "status": 409 }线程1释放锁
DELETE files/file/global
线程2加锁
PUT /files/file/global/_create {}响应
{ "_index": "files", "_type": "file", "_id": "global", "_version": 3, "result": "created", "_shards": { "total": 2, "successful": 1, "failed": 0 }, "_seq_no": 2, "_primary_term": 1 }加锁成功，然后执行事务方法。
优缺点全局锁本质上是所有线程都用_create语法来创建id为global的文档，利用Elasticsearch对_create语法的校验来实现锁的目的。
优点：操作简单，容易使用，成本低。
缺点：直接锁住整个索引，除了加锁的那个线程，其他所有对此索引的线程都block住了，并发量较低。
适用场景：读多写少的数据，并且加解锁的时间非常短，类似于数据库的表锁。
注意事项：加锁解锁的控制必须严格在程序里定义，因为单纯基于doc的锁控制，如果id固定使用global，在有锁的情况，任何线程执行delete操作都是可以成功的，因为大家都知道id。
document level级别的锁document level级别的锁是更细粒度的锁，以文档为单位进行锁控制。
我们新建一个索引专门用于加锁操作：
PUT /files-lock/_mapping/lock { "properties": { } }我们先创建一个script脚本，ES6.0以后默认使用painless脚本：
POST _scripts/document-lock { "script": { "lang": "painless", "source": "if ( ctx._source.process_id != params.process_id ) { Debug.explain('already locked by other thread'); } ctx.op = 'noop';" } }Debug.explain表示抛出一个异常，内容为already locked by other thread。
ctx.op = 'noop'表示不执行更新。
线程1增加行锁，此时传入的process_id为181ab3ee-28cc-4339-ba35-69802e06fe42
POST /files-lock/lock/1/_update { "upsert": { "process_id": "181ab3ee-28cc-4339-ba35-69802e06fe42" }, "script": { "id": "document-lock", "params": { "process_id": "181ab3ee-28cc-4339-ba35-69802e06fe42" } } }