的基础与案例进行了通俗易懂的解释读下来也有不少收获所以打算记录一下。

果真官方文档才是最好的“菜鸟教程”。

贴上官方文档

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

_id

文档唯一标识可以通过它检索唯一的文档。

当创建一个新文档的时候要么自己提供

_id要么让

注意其中操作“删除文档”也并不会立即将文档从磁盘中删除只是将文档标记为已删除状态即软删。

随着我们不断索引更多的数据ES

Update

集群的多次网络交互开销。

通过减少检索和重建索引步骤之间的事件也减少了其他进程的变更带来冲突的可能性。

但是这不能完全消除冲突的可能性可能还是会有某个进程在

update

是分布式的当文档创建、更新或删除的时候新版本的文档必须复制到集群中的其他节点。

ES

也是异步和并发的这意味着这些复制请求被并行发送并且到达目的地时也许是「乱序」的ES

中每个文档都有一个

来确保变更以正确的顺序执行如果旧版本的文档在新版本之后到达可以被简单的忽略。

_version

版本号还可以进行更新的乐观并发控制这可以确保应用中相互冲突的变更不会导致数据冲突。

我们可以通过指定想要修改的文档的

_version

请求三个步骤不是原子的话就会产生冲突像下面的示意图所示就会产生更新数据覆盖的问题

API

「重建索引」的请求上。

如果另一个进程修改了处于「检索」和「重建索引」步骤之间的文档那么

_version

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

retry_on_conflict

/website/pageviews/1/_update?retry_on_conflict5

{script

的这个角度上来说就不能开启重试逻辑比方在更新账户余额场景下非递增递减操作先到的

request1

的有序如果放在整个分布式系统中去看比方说消息系统生产者发送消息消费者消费并更新

EScanal