当前位置：首页 > news >正文

ElasticSearch-文档元数据乐观并发控制

news 来源：原创 2025/5/23 6:48:22

文章目录

什么是文档？
文档元数据
文档的部分更新
Update 乐观并发控制

最近日常工作开发过程中使用到了 ES，最近在检索资料的时候翻阅到了 ES 的官方文档，里面对 ES 的基础与案例进行了通俗易懂的解释，读下来也有不少收获，所以打算记录一下。果真官方文档才是最好的“菜鸟教程”。

贴上官方文档：

Elasticsearch:权威指南-基础入门

什么是文档？

Elasticsearch 中，术语文档有着特定的含义。它是指最顶层或者根对象, 这个根对象被序列化成 JSON 并存储到 Elasticsearch 中，指定了唯一 ID。可以简单理解为我们平时操作存储的对象在 ES 中通过 JSON 序列化存储的内容，是 ES 中操作的最小单位。

{"name":         "John Smith","age":          42,"confirmed":    true,"join_date":    "2014-06-01","home": {"lat":      51.5,"lon":      0.1},"accounts": [{"type": "facebook","id":   "johnsmith"},{"type": "twitter","id":   "johnsmith"}]
}

文档元数据

一个文档不仅包含着其本身的数据，也包含文档有关的信息，可以称之为「元数据」。

三个必须的元数据元素如下：

_index

文档在哪存放，就是我们平时建立的索引
_type

文档表示的对象类别，这个平时用的比较少，算是同一索引下的一个更细的类别划分
_id

文档唯一标识，可以通过它检索唯一的文档。当创建一个新文档的时候，要么自己提供 _id，要么让 ES 自动生成

文档的部分更新

ES update API 似乎对文档直接进行了修改，但是实际上 ES 中文档是「不能被修改，只能被替换」，详细的过程如下：

从旧文档构建 JSON
更改该 JSON
删除旧文档
索引一个新文档

注意：其中操作“删除文档”也并不会立即将文档从磁盘中删除，只是将文档标记为已删除状态，即软删。随着我们不断索引更多的数据，ES 才会在后台线程中清理标记为已删除的文档。

Update API 整体遵循 检索-修改-重建索引 的处理过程，并且这三步都是发生在 ES 节点内部的，避免了客户端和 ES 集群的多次网络交互开销。通过减少检索和重建索引步骤之间的事件，也减少了其他进程的变更带来冲突的可能性。但是这不能完全消除冲突的可能性，可能还是会有某个进程在 update 设法重建索引前，另一进程请求修改了文档。

Update 乐观并发控制

ES 是分布式的，当文档创建、更新或删除的时候，新版本的文档必须复制到集群中的其他节点。ES 也是异步和并发的，这意味着这些复制请求被并行发送，并且到达目的地时也许是「乱序」的，ES 需要一种方法确保文档的旧版本不会覆盖新的版本。

ES 中每个文档都有一个 _version 号，可以当作其元数据的一部分，当文档被修改时，版本号会递增。ES 可以使用 _version 来确保变更以正确的顺序执行，如果旧版本的文档在新版本之后到达，可以被简单的忽略。

并且通过 _version 版本号还可以进行更新的乐观并发控制，这可以确保应用中相互冲突的变更不会导致数据冲突。我们可以通过指定想要修改的文档的 _version 来达到这个目的，如果该版本不是当前版本号，我们的请求会失败。

Update API 乐观并发控制：

Update API 的 检索-修改-重建索引 步骤拆解下来就是如下的 Get - Update - Put 请求，三个步骤不是原子的话就会产生冲突，像下面的示意图所示就会产生更新数据覆盖的问题

在这里插入图片描述

为了避免并发更新时产生的数据丢失，Update API 在「检索」步骤时检索得到当前文档的 _version 号，并传递版本号到「重建索引」的请求上。如果另一个进程修改了处于「检索」和「重建索引」步骤之间的文档，那么 _version 号将不匹配，更新请求将会失败。这种场景就是先到的 request1 由于执行时间过长，反倒被后到的&执行时间更短的 request2 给冲突导致失败了。

在增量操作无关顺序的场景下，两个进程更新操作发生的顺序不太重要（比方说两个进程都对页面访问量进行递增计数），那么由于冲突导致更新失败的请求，唯一需要做的就是重试。

这可以通过设置参数 retry_on_conflict 来自动完成，这个参数规定了失败之前 update 应该重试的次数，它的默认值是 0，也就是默认不重试。下面的例子表示失败之前需要重试 5 次。

POST /website/pageviews/1/_update?retry_on_conflict=5 
{"script" : "ctx._source.views+=1","upsert": {"views": 0}
}

但是在其他情况下变更可能要求是「有序的」，那么在 ES update 的这个角度上来说，就不能开启重试逻辑，比方在更新账户余额场景下（非递增递减操作），先到的 request1 被后到的 request2 冲突失败了，此时 request2 是最新的数据，ES 也是能够维持「最终一致性的」，但如果让 request1 重试一次，账户余额就会被老的数据覆盖了，显然是不能接受的。

再拓展一下思路，上面仅仅是在 ES 系统内保证 update 的有序，如果放在整个分布式系统中去看，比方说消息系统生产者发送消息，消费者消费并更新 ES（canal 就有这种模式），如果要保证分布式系统的全局有序，就得额外考虑 1.生产者到 MQ 2.MQ 到消费者 3.消费者到更新ES 每个环节的「有序性」。

文章目录

什么是文档？

文档元数据

文档的部分更新

Update 乐观并发控制

相关文章：