我们将选择Google Cloud Pub/Sub作为我们的消息总线。有些消息需要在低延迟持续时间内发送，比如小于100-200ms。
我在某个地方读到，在大量消息中，它表现良好，但对于每秒数百条消息这样的少量消息，Pub/Sub可能会产生高延迟。
在前面的问题中，主题也不清楚。2016年谷歌云发布/订阅延迟是多少。
是否有任何关于发布/订阅延迟以及与消息量的关系的定义指标？
Cloud Pub/Sub的设计考虑到了大量的消息，因此如果消息吞吐量过低，它有时会遇到困难。这与Pub/Sub如何平衡侦听器之间的拉取请求有关。
回到你的问题，关于这种行为没有定义的指标，也没有最小延迟或神奇的消息数量，你可以说它被认为是"高负载"。事实上，这取决于工人数量、批量大小、每条消息的处理时间等因素。
我发现了另一个StackOverflow答案，它更多地谈到了Pub/Sub的有效用例(每秒数千条消息(，以及为什么建议Cloud Pub/Sub使用高负载。
编辑：
在这个主题的基础上，向Pub/Sub实现添加异步层可以帮助提高其性能，包括在低消息量场景中的延迟。Spotify在与Pub/Sub合作时，意识到了这一点，并创建了自己的异步云Pub/Sub客户端。他们现在建议使用谷歌的java客户端，但值得考虑