文章目录
- 什么是文档？
- 文档元数据
- 文档的部分更新
- 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 每个环节的「有序性」。
)
