ElasticStack系列之六 & 版本冲突处理之乐观锁

悲观并发控制（PCC）

这一点在关系数据库中被广泛使用。假设这种情况很容易发生，我们就可以阻止对这一资源的访问。典型的例子就是当我们在读取一个数据前先锁定这一行，然后确保只有读取到数据的这个线程可以修改这一行数据。

乐观并发控制（OCC）

Elasticsearch所使用的。假设这种情况并不会经常发生，也不会去阻止某一数据的访问。然而，如果基础数据在我们读取和写入的间隔中发生了变化，更新就会失败。这时候就由程序来决定如何处理这个冲突。例如，它可以重新读取新数据来进行更新，又或者它可以将这一情况直接反馈给用户。

 

Elasticsearch内部版本号

在Elasticsearch中，更新请求实际上是分为两个阶段，获取文档，修改文档，然后保存文档。

那么当两个更新请求同时要修改文档的时候，系统乐观的认为不会有两个并发请求对一个系统操作。

文档原本的版本为1，请求A获取了version为1的文档，请求B也获取了version为1的文档，然后请求A修改完文档后，并且先执行了保存操作，这个时候，系统中的文档version变为了2。这个时候，B再执行保存操作的时候，告诉系统我要修改version为1的文档。系统就会抛出一个错误，说文档版本不匹配。然后这个错误由应用程序自己来进行控制。

这种机制在请求量大的时候会比悲观锁机制好。但是缺点是需要程序处理版本冲突错误，可能一般的方法是封装更新操作，并且设置重复重试次数。

注意这里的更新指的是：

　　curl -XPOST http://localhost:9200/test/test/1/_update -d '{"msg": "test"}'

　　而不是：

　　curl -XPOST http://localhost:9200/test/test/1 -d '{"msg": "test"}'

这个是create，这种在ES内部没有乐观锁的概念，是直接覆盖，这种想解决数据被覆盖，就要显示的带着version