添加 include_docs=true 时 CouchDB seq 编号发生变化答案

【问题标题】：CouchDB seq number changes when adding include_docs=true添加 include_docs=true 时 CouchDB seq 编号发生变化
【发布时间】：2018-08-27 16:01:34
【问题描述】：

在使用 CouchDB (2.1.1) 中的 _changes API 时，我注意到当我添加 ?include_docs=true 时，结果记录的 seq 数量是不同的。这是预期的吗？如果是，有人可以帮我理解其背后的逻辑吗？

更多信息：

创建一个数据库，我称之为测试：
在这个新的测试数据库上创建三个文件。这些可以只有 id，没有别的：

现在调用 API 两次，一次使用 ?include_docs=true，另一次没有。

致电 ?include_docs=true

打电话没有?include_docs=true

如您所见，两个请求上的 id 值从响应中条目的顺序来看是不同的，此外，seq 哈希看起来相同，但它的“字符串部分”最终不同其中。所以我的问题是，鉴于我只想添加文档参考，为什么它们不一样？这是预期的吗？如果有，谁能解释一下？

【问题讨论】：

@Flimzy，实际上我正在比较具有和不具有?include_docs=true 的同一数据库的_changes 端点的结果。我试图在最后两张截图中显示的是，不仅 seq 哈希不同，而且文档的顺序也不同，这是我无法理解的......如果你检查第三张截图（带有chrome windows并排）你会看到相同的数据库，相同的文件，但它们有不同的顺序和seq哈希，尽管唯一不同的是在URL上添加?include_docs=true
哦，对，有道理。
Sequence number bug in CouchDB 2 or is there another way to compare sequence numbers?的可能重复

标签： rest couchdb couchdb-2.0

【解决方案1】：

您必须考虑到 _changes 提要没有完全排序。更改是根据数据库的节点和分片集计算的。 CouchDB 从不同的分片中检索更改，然后将它们组合成一个流。

更改提要的序列号背后的逻辑非常复杂，它反映了响应更改提要请求的每个分片的状态。

如果您解码 seq binary_to_term(couch_util:decodeBase64Url(EncodedStringHere)) 的字符串部分，您将看到用于构成该文档的 chages 条目的分片状态。

这里的问题是，您不能依赖更改提要顺序，因为它可能会发生变化。

【讨论】：

尽管我可以理解为什么它们可能会出现故障，但我仍然不明白为什么同一资源的 seq 哈希完全不同（参见带有 id: "first" 的哈希）在第三个屏幕截图上）。根据我的理解，seq 表示将更改添加到数据库的顺序，这也是我从 couchdb 文档中理解的。我在逻辑上期望的是，结果数组可能是乱序的，但是在_changes 上带有id:X 和seq:Y 的文档也应该在_changes?include=docs 上具有id:X 和seq:Y。
Seq 是根据每个请求计算的，它取决于从系统上不同分片/节点获得的响应。当您请求文档时，更改恢复策略可能会有所不同，这会导致同一文档的序列号不同。请不要在逻辑中依赖此序列号。你唯一可以依赖的是last_seq。