这是我的理解(例如从这里)，Cosmos DB更改Feed不保证触发每次更新的事件。例如，当对同一文档的两次更新几乎同时发生时，可能会发生更改Feed处理器(例如，侦听更改Feed的Azure函数)仅触发一次，即两次更新中的较晚一次。首先，我的理解对吗?如果是:
- 根据您的经验，为每个事件单独触发更改事件的更新的典型最小时间间隔是什么?(不是一个确切的值，但只是数量级已经有帮助了。)
- 此时间间隔是否有SLA ?
更改提要是基于轮询而不是基于事件的，尽管这取决于您使用增量模型轮询更改的频率。
处理器只跟踪每个分区读取的最高LSN，并从该书签点开始请求下一批更改(按LSN顺序)。
每次更新文档时，其关联的LSN都会增加，因此，为了在更改提要中返回特定版本，更改提要处理器需要在更新文档之前请求包含该LSN的批处理。
对于Azure函数，您可以减少feedPollDelay以使您不太可能错过更改
(可选)两次轮询之间的延迟时间(毫秒)在所有当前更改完成后，为提要上的新更改划分分区排干。默认为5000毫秒，即5秒。
如果您的更改非常接近，您可能仍然会错过它们。有一个"全保真度变化反馈"。选项将在某个时候返回所有更改，但我不确定如何进入预览版，也不确定何时将与Azure功能集成。