在 GKE 中，如果我有一个设置为使用 pull 方法的 Pub/Sub 主题和一个充当该主题订阅者的 API，如果此 API 具有 3 的复制（规范。副本：3)，API（客户端）的开箱即用行为是什么？
即当一条消息被推送到主题时，假设 API 是来自主题 (https://cloud.google.com/pubsub/docs/pull#asynchronous-pull) 的 asynchronously pulling 消息并且具有 3 个复制，那么所有 3 个 pod 是否同时拉取消息（并以重复结束）？幕后是否有某种负载平衡？开箱即用的行为是什么？
【问题讨论】：
标签： google-cloud-platform google-kubernetes-engine google-cloud-pubsub
消息在与同一订阅连接的订阅客户端之间进行负载平衡。一条给定的消息一次只能对一个订阅者未完成，直到ack deadline 过期，此时它可能会重新传递给不同的订阅者客户端。该服务还分别尊重每个订阅者客户端的flow control 设置，并且不会将消息发送到受流控制的客户端，而是将它们路由到其他客户端。有关订阅者行为的更多信息，请访问subscriber documentation。
因此，如果 3 个副本连接到同一个订阅，主题的消息将在它们之间进行负载平衡，即它们将接收不同的消息子集。您应该提供足够的副本，以便总体上它们可以比消息发布到主题更快地处理。
如果您希望 3 个副本分别接收所有消息，请为每个副本使用不同的订阅。
【讨论】：
您在 youtube 上有一个很棒的视频系列：Google Cloud youtube channel。您可以深入了解每种订阅的行为、重试策略等。
立即回答您的问题：是的，有一个负载均衡器，并且根据订阅者的数量发送消息。但这并不是真正的循环赛。引擎盖下的优化可以将消息块发送给每个订阅者（根据它们的大小和数量）。我的意思是，如果您同时发送 3 条测试消息，则 3 条将发送给同一个订阅者。
消息仅在订阅（推送或拉取）中重复。
【讨论】：