问题，有关使用AutoscalingAlgorithmType.THROUGHPUT_BASED的PubSubIO在DataflowRunner中的工作方式：PubSubIO如何确定应以多快的速度拉订阅（即拉频率和每次拉中的消息数）？我想知道这是否与拉出消息和发送确认之间的时间有关？
背景：我正在运行一个管道，该管道从PubSub提取消息并将其发送给第三方供应商。这个问题来自我在2种不同设置下运行管道时观察到的有趣行为。
原始设置是在全局窗口下处理所有内容，根据我从project.locations.jobs.get获得的信息，所有DoFn都合并为一个步骤。但是，此设置遇到自动缩放问题，在该问题中，数据流作业可以自动缩放到多个工作程序，但总体吞吐量没有增加。由于确认仅在completeBundle发生，因此也触发了大量extendAcknowledgeDeadline请求。
第二种设置是添加MapElement，GroupByKey和ParDo，它们首先将字符串消息映射到KV，其中key和value都是消息字符串，然后{ {1}}在1秒钟的固定窗口内，并在GroupByKey之后立即将KV最终解析回字符串。 Dataflow documentation提出了打破融合优化的建议。它还解决了原始设置中的自动缩放问题，并提高了单个工作人员的吞吐量。此设置中的消息几乎会立即得到确认。
这种观察使我想知道PubSubIO.readStrings的吞吐量是否由到达捆绑包确认所需的时间来确定，例如PubSub的连接数是固定的，并且在确认先前提取的捆绑包之前，每个连接都不会释放到新的提取中。