河南企业网站推广,公司网页设计业务介绍,网站与app的区别,工信部网站 验证码文章目录 什么是文档#xff1f;文档元数据文档的部分更新Update 乐观并发控制 最近日常工作开发过程中使用到了 ES#xff0c;最近在检索资料的时候翻阅到了 ES 的官方文档#xff0c;里面对 ES 的基础与案例进行了通俗易懂的解释#xff0c;读下来也有不少收获#xff0… 文章目录 什么是文档文档元数据文档的部分更新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_conflict5
{script : ctx._source.views1,upsert: {views: 0}
}但是在其他情况下变更可能要求是「有序的」那么在 ES update 的这个角度上来说就不能开启重试逻辑比方在更新账户余额场景下非递增递减操作先到的 request1 被后到的 request2 冲突失败了此时 request2 是最新的数据ES 也是能够维持「最终一致性的」但如果让 request1 重试一次账户余额就会被老的数据覆盖了显然是不能接受的。
再拓展一下思路上面仅仅是在 ES 系统内保证 update 的有序如果放在整个分布式系统中去看比方说消息系统生产者发送消息消费者消费并更新 EScanal 就有这种模式如果要保证分布式系统的全局有序就得额外考虑 1.生产者到 MQ 2.MQ 到消费者 3.消费者到更新ES 每个环节的「有序性」。
