GKE：具有 3 个副本的 Pubsub 和 Pod 部署

Posted 2023-02-16

【中文标题】GKE：具有 3 个副本的 Pubsub 和 Pod 部署

【英文标题】：GKE: Pub/Sub and Pod deplyment with 3 replicas

【发布时间】：2021-05-07 06:16:58

【问题描述】：

在 GKE 中，如果我有一个设置为使用 pull 方法的 Pub/Sub 主题和一个充当该主题订阅者的 API，如果此 API 具有 3 的复制（规范。副本：3)，API（客户端）的开箱即用行为是什么？

即当一条消息被推送到主题时，假设 API 是来自主题 (https://cloud.google.com/pubsub/docs/pull#asynchronous-pull) 的 asynchronously pulling 消息并且具有 3 个复制，那么所有 3 个 pod 是否同时拉取消息（并以重复结束）？幕后是否有某种负载平衡？开箱即用的行为是什么？

【参考方案1】：

消息在与同一订阅连接的订阅客户端之间进行负载平衡。一条给定的消息一次只能对一个订阅者未完成，直到ack deadline 过期，此时它可能会重新传递给不同的订阅者客户端。该服务还分别尊重每个订阅者客户端的flow control 设置，并且不会将消息发送到受流控制的客户端，而是将它们路由到其他客户端。有关订阅者行为的更多信息，请访问subscriber documentation。

因此，如果 3 个副本连接到同一个订阅，主题的消息将在它们之间进行负载平衡，即它们将接收不同的消息子集。您应该提供足够的副本，以便总体上它们可以比消息发布到主题更快地处理。

如果您希望 3 个副本分别接收所有消息，请为每个副本使用不同的订阅。

【参考方案2】：

您在 youtube 上有一个很棒的视频系列：Google Cloud youtube channel。您可以深入了解每种订阅的行为、重试策略等。

立即回答您的问题：是的，有一个负载均衡器，并且根据订阅者的数量发送消息。但这并不是真正的循环赛。引擎盖下的优化可以将消息块发送给每个订阅者（根据它们的大小和数量）。我的意思是，如果您同时发送 3 条测试消息，则 3 条将发送给同一个订阅者。

消息仅在订阅（推送或拉取）中重复。