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

文章目录

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

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

贴上官方文档：

什么是文档？

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

json 复制代码

{
    "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 次。

json 复制代码

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 每个环节的「有序性」。