如果设置得太低，则“推送订户吞吐量”的Cloud PubSub配额将不适用

Question

我们尝试通过将“推送订户吞吐量kB”的配额设置为1，对Cloud PubSub推送订户强制实施一定的速率限制，这实际上意味着PubSub与推送订户的处理速率不得超过1 kbps。

但是，实际吞吐量可能会更高，达到6-8 kbps。

为什么不按预期限制吞吐量？

更多详细信息：

目标是每秒限制50条消息。

我们可以假定平均消息大小，出于测试目的，我们使用50字节的消息，即50字节* 60秒=每秒3000字节，或每秒3 kbps的消息。通过将配额设置为1，我们期望的速度将少于PubSub每秒发送的50条消息。在测试过程中，我们获得的不仅仅是这些。

Answer 1

目前，在Google Cloud Pub / Sub中实施强制订阅者配额存在一个已知问题。

通常，推送用户配额并不是尝试执行流控制的好方法。为了实现真正的流量控制，最好使用请求订阅者和client libraries。用户中流量控制的目标是防止用户不知所措。在客户端库中，流控制是根据未完成的消息和/或未完成的字节定义的。当达到这些限制之一时，Cloud Pub / Sub会暂停传递更多消息。

基于速率的流控制的问题在于，它不能很好地解决订户或其下游依赖项的意外问题。例如，假设订户接收到消息，写入数据库，然后确认该消息。如果数据库遭受高延迟或一段时间内不可用，则基于速率的流控制仍将向订户传递更多消息，这将备份并最终可能导致其内存过载。使用基于未决消息或字节的流控制时，数据库不可用（这会阻止订户确认消息）这一事实意味着将完全停止传递。在这种情况下，数据库无法处理任何消息或处理消息的速度非常慢，因此即使以非常低的速率发送更多消息仍然对订户有害。