如果在应用更新之前更改了文档，那么使用update API的文档的部分更新似乎会失败：
为避免丢失数据，更新API将检索当前的_version 检索步骤中的文档，并将其传递给索引 在重新索引步骤期间请求。如果另一个进程改变了 检索和重新索引之间的文档，然后_version数字不会 匹配，更新请求将失败。
然后继续说你可以提供retry_on_conflict，如果发生冲突，会重试写入：
对于部分更新的许多用途，文档都没有关系 被改变了......
这可以通过设置自动完成 retry_on_conflict参数指向更新的次数 失败前重试;它默认为0。
因此，如果我使用update API与{3}的retry_on_conflict，而不提供_version字段，则ES将在内部失败一次（如果确实发生冲突），然后重试并覆盖与之冲突的值？
看起来似乎是这样，因为
...默认情况下，更新API采用last-write-wins方法
注意：我正在使用ES 1.5
答案 0 :(得分：1)
是的，就是这样。关于retry and overwrites the value that it was conflicting with声明的澄清：冲突与文档的版本（不是文档中的任意字段），让我们明确这一点，这是ES GETing之间的内部冲突文档并实际编写新的（更新的）文档（这两个操作是_update操作的一部分）。
并且它不会覆盖与之冲突的值，它是另一个更新操作，只要版本检查正常就会成功，是的，将更新索引中的文档。
如果您需要确保更新按特定顺序，则需要使用版本。