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

时间:2021-06-20 13:58:36

标签: google-cloud-pubsub broadcast

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

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

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

这让我想到了我的问题 - 我如何通过 PubSub 实现这一点?

  • 目前我正在使用拉订阅,我需要使用推送订阅吗?也许这可以让所有订阅者同时交付?
  • 在 Pull 模型中,如果订阅者没有 .ack() 消息,大概允许重新传递消息,但消息最终发送到其适当的订阅者可能需要很长时间(违背了 Web Sockets 的目的,即“实时”更新)- 这是对它在拉订阅模型中的工作方式的公平评估吗?
  • 我是否使用了错误的工具来完成这项工作?这是可能的,但我希望我只需要对当前工具进行不同的使用

1 个答案:

答案 0 :(得分:3)

在这种情况下,我将使用这种设计:

  • 仅创建一个发布所有消息的主题
  • 当 VM 启动时,VM 会为自己创建一个对 PubSub 主题的请求订阅
  • 当虚拟机关闭时,虚拟机删除订阅(例如在关闭脚本中)

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

  • VM 检查它是否适合它
    • 如果不是,确认消息(将其从订阅中删除,而不是其他人)
    • 如果是,处理并确认消息

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


编辑 1

原理如下:你在topic中发布1条消息,然后在所有订阅中复制该消息,订阅者(每个订阅1个或多个)收到1个订阅的消息子集(或所有消息,如果订阅中只有 1 个订阅者)

这就是为什么,在我的提议中:

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