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

问题描述

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

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

解决方法

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

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

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

对于 Azure 函数，您可以减少 feedPollDelay 以减少错过更改的可能性

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

如果您的更改非常接近，您可能仍然会错过它们。有一个“full fidlelity change feed”选项会在某个时候返回所有更改，但我不确定如何进入预览版或何时正式发布并与 Azure 功能集成。