我正在使用 Cosmos Change Feed Processor，在我的应用程序中使用 Java 来使用 Cosmos NoSql DB 容器的 Cosmos Change Feed
根据文档，如果使用更改源处理器方法，在我们开始使用更改源时，该点之前的所有插入/更新都将作为单个快照交付。
由于我正在执行的过程是在非生产环境中（在产品中执行之前进行测试），因此自从我的更改提要消耗开始以来，容器没有大量的插入/更新。
从以上两点，我们可以得出结论，更改源处理器返回的估计延迟（当运行和使用更新时）不应比容器中的文档总数高很多
但是，我认为估计的延迟约为 1.3 亿，因为我的容器中只有约 700 万条记录。
我的容器只有 1 个物理分区（因此只有 1 个更改源处理器实例在运行），下面是我用来计算估计延迟的代码。
AtomicInteger totalLag = new AtomicInteger();
List<ChangeFeedProcessorState> currentState = changeFeedProcessor.getCurrentState().block();
if (CollectionUtils.isEmpty(currentState)) {
System.out.println("Unexpected METRICS :: STATES is empty");
continue;
}
for (ChangeFeedProcessorState changeFeedProcessorState : currentState) {
totalLag.addAndGet(changeFeedProcessorState.getEstimatedLag());
}
System.out.println(totalLag.get());
有人可以提供这方面的专业知识吗
TL;DR 如果您阅读文档的字面意思（不多！）而不是您想要的内容，则估计滞后绝对不是“剩余待处理的文档数量”...“估计器”术语也明确旨在传达这样一个事实：这不是也不可能是一个精确的指标。
滞后是当前检查点“位置”和最近写入的位置标识符的函数。该位置也（大约）用于延续标记。每次写入或批量写入都会向前推进（甚至是更新）。您不能依赖或假设没有间隙等（考虑任何数量的原因，例如复制、回滚工作等）
换句话说，如果您对文档进行插入和 20 次更新，则计数将向前移动 21 或更多。如果您在单个逻辑分区中更新 2 个文档，我认为可能只会将其移动一个。
除了对真实数据进行实际遍历（由于相关的 RU 消耗，这会产生很多副作用）之外，根本没有办法知道文档方面的实际差距是什么。
幸运的是，这对于大多数现实世界的案例来说并不重要；对于附加到变更源的任何内容，可以达到的吞吐量（以及可以实现的一致性）存在自然的可变性 - IME 很少有有趣的系统具有足够稳定和一致的每个文档的处理成本。
最好的办法是将其放在图表上，并在比较合理相关的情况时将其用作近似指标（相同数量的文档，具有相同的处理成本，具有相同的处理能力来处理从提要中脱落的项目）