GCP PubSub - 广播消息 - 只有相关订阅者处理消息答案

【问题标题】：GCP PubSub - broadcast message - only relevant subscriber handles messageGCP PubSub - 广播消息 - 只有相关订阅者处理消息
【发布时间】：2021-06-20 13:58:36
【问题描述】：

我在负载平衡的环境中使用 GCP PubSub 作为 Web Sockets 的后端。当前的实现为负载均衡器后面的每个服务器都有一个主题，以及最终用户和服务器之间的映射。当我希望向特定用户发送消息时，我使用映射来确定将其发布到哪个主题。

这可行，但它有很多移动部件，并且需要在通过缩减或推出应用程序的更新版本来移除服务器时清理主题。

我现在正在探索一种更复杂的实现，其中只有一个主题。由于每台服务器都知道它的最终用户，理论上我可以向这个单一主题发布一条消息，并且每台服务器都可以检查该消息，并将其与其用户列表进行比较。只有当前为消息中指定的最终用户提供 Web Socket 连接的服务器才会处理它。

这让我想到了我的问题 - 我如何通过 PubSub 实现这一目标？

目前我使用的是 Pull 订阅，我需要使用 Push 订阅吗？也许这样可以同时向所有订阅者交付？
在 Pull 模型中，如果订阅者不.ack() 消息，可能会允许重新传递消息，但最终将消息发送给相应的订阅者可能需要很长时间（击败Web Sockets 的目的，即“实时”更新）——这是对它在 Pull 订阅模型中的工作方式的公平评估吗？
我是否使用了错误的工具来完成这项工作？这是可能的，但我希望我只需要对当前工具进行不同的使用

【问题讨论】：

服务器处理的用户列表在服务器启动时是已知的还是可以进化的？你如何在服务器之间分片用户？什么是分区键？
用户在运行时与服务器相关联。打开 Web 套接字的请求通过负载均衡器发送，并根据其配置路由到特定服务器。此时，在映射表中记录了一个条目，将用户与提供 Web 套接字连接的特定服务器相关联。
您可以并行拥有多少台服务器，以及多少个 Web 套接字连接（实际上，您现在和将来预计每秒或每小时有多少条消息）？消息发布和消息处理之间的预期最大延迟是多少？
这些都是很好的问题，因为应用程序在其生命周期中是新生的，我没有任何经验数据可以准确地回答它们。目前，这些属性中最重要的是消息发布和处理之间的延迟，我们希望将其降至最低。想象一下，一位用户索取了一张音乐会门票（数量有限），我们希望其他用户尽可能接近实时地看到更新后的票数。

标签： google-cloud-pubsub broadcast

【解决方案1】：

在这种情况下，我将使用这种设计：

只创建一个发布所有消息的主题
当 VM 启动时，VM 会为自己创建一个 PubSub 主题的拉取订阅
VM 关闭时，VM 会删除订阅（例如在关闭脚本中）

然后，当一条消息到达时，它只发布在一个 PubSub 主题中，并散播到所有活动订阅中。 VM 不断地拉取消息。当消息到达拉取队列时：

VM 检查它是否适合它
- 如果否，则确认消息（将其从订阅中删除，而不是为其他订阅）
- 如果是，处理并确认消息

通过这种设计，您可以最大限度地减少延迟，并且只在一个主题中发布。但是，您会复制大量消息并消耗处理能力来丢弃所有不相关的消息。

编辑 1

原理如下：您在主题中发布 1 条消息，然后该消息在所有订阅中重复，订阅者（每个订阅 1 个或多个）接收 1 个订阅的消息子集（或所有消息，如果订阅中只有 1 个订阅者）

这就是为什么，在我的提议中：

每个 VM 创建自己的订阅，并且是其上唯一一个接收主题中发布的所有消息副本的订阅者。
确认不相关的消息以将它们从队列中删除。它们只会从当前 VM 的当前订阅中删除。

【讨论】：

感谢您的回答，您是否知道关于消息的 ack 调用的文档在哪里？
另外，消息扇出到所有节点是默认的，还是有一些特殊的配置？我担心消息被传递到单个节点，然后如果在超时后未收到确认，则在其他节点上重试。任何与此相关的文档都会很有帮助。
扇出默认在所有订阅之间执行，而不是订阅者之间。我更新了我的答案。让我知道它是否更清楚！我向您推荐 PubSub 上的这个 youtube 系列：youtube.com/hashtag/pubsubmadeeasy
感谢您，在尝试了一些简单的发布者和订阅者脚本后，我了解您提出的最后几点。我认为转向一个主题会让我的生活更轻松。我还学会了尽量减少单个消息的延迟，我将为此主题禁用批处理。