Cosmos DB Change Feed 的时间分辨率是多少？

Question

据我了解（例如来自此处），Cosmos DB 更改源不能保证每次更新都会触发事件。例如，当对同一文档的两次更新几乎同时发生时，可能会发生更改源处理器（例如侦听更改源的 Azure 函数）仅触发一次，即两次更新中的较晚一个更新。首先我的理解正确吗？如果是：

1. 根据您的经验，更新的典型最小时间间隔是多少，以便为每个事件单独触发更改事件？ （不是确切的值，但只是数量级就已经很有帮助了。）
2. 此时间间隔有 SLA 吗？

Answer 1

更改源是基于轮询而不是基于事件，因此取决于您使用增量模型轮询更改的频率。

处理器仅跟踪每个分区读取的最高 LSN，并请求从该书签点开始的下一批更改（按 LSN 顺序）。

每次更新文档时，其关联的 LSN 都会增加，因此，为了在更改源中返回特定版本，更改源处理器需要在文档更新之前请求包含该 LSN 的批次。

对于 Azure 函数，您可以减少

feedPollDelay

以减少错过更改的可能性

（可选）轮询之间的延迟时间（以毫秒为单位） 在所有当前更改完成后，对 Feed 上的新更改进行分区 耗尽。默认值为 5,000 毫秒，即 5 秒。

如果您的更改非常接近，您可能仍然会错过它们。有一个“完整的保真更改提要”选项将在某个时候返回所有更改，但我不确定如何进入预览版或何时它将成为 GA 并与 Azure 功能集成。

Answer 2

如果我在插入所有记录后，通过在 cosmos 中逐一添加每条记录来在 cosmos 中提供 200 条记录，那么我也会提供单个 feed。我还运行了一个查询来更新所有记录中的一个参数。 在上面的场景中，我得到了 2 个 cosmos 触发器，其中一个触发器有 200 条记录 + 20 条记录用于我在最后运行的单个查询，第二个触发器有 180 条记录，我使用单个查询运行。

因此，我对 cosmos db 在什么时间间隔之后相继触发感到有点困惑？