悲观锁
这种方法被关系型数据库广泛使用，它假定有变更冲突可能发生，因此阻塞访问资源以防止冲突。 一个典型的例子是读取一行数据之前先将其锁住，确保只有放置锁的线程能够对这行数据进行修改。
乐观锁
Elasticsearch 中使用的这种方法假定冲突是不可能发生的，并且不会阻塞正在尝试的操作。然而，如果源数据在读写当中被修改，更新将会失败。应用程序接下来将决定该如何解决冲突。例如，可以重试更新、使用新的数据、或者将相关情况报告给用户。
Elasticsearch 中对文档的 index ， GET 和 delete 请求时，我们指出每个文档都有一个 _version （版本）号，当文档被修改时版本号递增。
Elasticsearch 使用这个 _version 号来确保变更以正确顺序得到执行。如果旧版本的文档在新版本之后到达，它可以被简单的忽略。
我们可以利用 _version 号来确保应用中相互冲突的变更不会导致数据丢失。我们通过指定想要修改文档的 version 号来达到这个目的。 如果该版本不是当前版本号，我们的请求将会失败。
所有文档的更新或删除 API，都可以接受 version 参数，这允许你在代码中使用乐观的并发控制，这是一种明智的做法。
乐观并发控制 - 外部系统版本号（version）只是其中一个实现方式，我们还可以借助外部系统使用版本控制，一个常见的设置是使用其它数据库作为主要的数据存储，使用 Elasticsearch 做数据检索， 这意味着主数据库的所有更改发生时都需要被复制到 Elasticsearch ，如果多个进程负责这一数据同步，你可能遇到类似于之前描述的并发问题。
如果你的主数据库已经有了版本号，或一个能作为版本号的字段值比如 timestamp，那么你就可以在 Elasticsearch 中通过增加 version_type=external到查询字符串的方式重用这些相同的版本号，版本号必须是大于零的整数， 且小于 9.2E+18(一个 Java 中 long 类型的正值)。
外部版本号的处理方式和我们之前讨论的内部版本号的处理方式有些不同， Elasticsearch 不是检查当前 _version 和请求中指定的版本号是否相同，而是检查当前_version 是否小于指定的版本号。如果请求成功，外部的版本号作为文档的新_version 进行存储。
外部版本号不仅在索引和删除请求是可以指定，而且在创建新文档时也可以指定。
例如，要创建一个新的具有外部版本号 5 的博客文章，我们可以按以下方法进行：
PUT /website/blog/2?version=5&version_type=external { "title": "My first external blog entry", "text": "Starting to get the hang of this..." }在响应中，我们能看到当前的 _version 版本号是 5 ：
{ "_index": "website", "_type": "blog", "_id": "2", "_version": 5, "created": true }现在我们更新这个文档，指定一个新的 version 号是 10 ：
PUT /website/blog/2?version=10&version_type=external { "title": "My first external blog entry", "text": "This is a piece of cake..." }请求成功并将当前 _version 设为 10 ：
{ "_index": "website", "_type": "blog", "_id": "2", "_version": 10, "created": false }如果你要重新运行此请求时，它将会失败，并返回像我们之前看到的同样的冲突错误，因为指定的外部版本号不大于 Elasticsearch 的当前版本号。
文档存储原理创建索引的时候我们只需要指定分片数和副本数，ES 就会自动将文档数据分发到对应的分片和副本中。那么文件究竟是如何分布到集群的，又是如何从集群中获取的呢？ Elasticsearch 虽然隐藏这些底层细节，让我们好专注在业务开发中，但是我们深入探索这些核心的技术细节，这能帮助你更好地理解数据如何被存储到这个分布式系统中。
文档是如何路由到分片中的当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？
首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
shard = hash(routing) % number_of_primary_shardsrouting 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。