具有拉订阅者设计缺陷的 Google PubSub？

如何解决具有拉订阅者设计缺陷的 Google PubSub？

我们使用的是googles steaming pull subscription，设计如下

我们正在做

1. 将文件从 FE（前端）发送到 BE（后端）
2. 将该文件转换为 ByteArray 并作为消息发布到 pubsub 主题（因此 ByteArray 作为消息）
3. 主题将该消息发送给订阅者，订阅者再次将 ByteArray 转换为文件
4. 转换后的文件订阅者发送到该工具
5. 工具用文件做一些很酷的事情并将状态通知订阅者
6. 该状态将变为 BE 和 BE 更新数据库并将该状态发送给 FE

现在在我们的订阅者中，当我们收到消息时，我们会立即确认并删除订阅者的侦听器，以便我们不再收到消息
当那个工具完成这些事情时，它会向订阅者发送状态（我们有快速服务器在订阅者上运行）和

after receiving status we are re-creating listener of subscriber to receive message

注意

• 该工具可能需要 1 小时或更长时间才能完成任务
• 我们正在使用排序键将消息正确分发到虚拟机

这段代码运行良好，但我的问题是

• 这是否有任何缺陷（bcz 我们删除侦听器然后重新创建它或类似的东西）
• 或任何更好的选择或 GCP 服务最适合此设计
• 或任何代码改进

编辑：
删除了代码示例

解决方法

我想说这个设计有几个部分是次优的。首先，在完成处理之前确认消息意味着您有消息丢失的风险。如果您的工具或订阅者在确认消息后但在处理完成之前崩溃，会发生什么？这意味着当进程开始备份时，它们将不会再次收到消息。您是否同意来自前端的请求可能永远不会被处理？如果没有，您将需要在处理完成后确认，或者 - 考虑到您的处理需要很长时间 - 将请求保留到数据库或某个存储中，然后确认消息。如果您无论如何都必须将文件保留在其他地方，您可能需要考虑将 Pub/Sub 排除在外，将文件写入 GCS 之类的存储，然后让订阅者直接从 GCS 中读出。>

其次，在收到每条消息时停止订阅者是一种反模式。您的订阅者应该在每条消息到达时接收和处理它。如果您需要限制并行处理的消息数量，请使用 message flow control。

此外，对密钥进行排序也不是“正确地将消息分发给 VM”的一种方式。订购键只是确保按顺序交货的一种方式。不能保证相同排序键的消息会持续发送到同一个订阅者客户端。事实上，如果您在收到每条消息后关闭订阅者客户端，那么另一个订阅者可能会收到下一条消息，因为您已经确认了之前的消息。如果您所说的“正确分发消息”只是希望按顺序传递消息，那么这是使用排序键的正确方法。

您说您为每个客户订阅了一个订阅，那么这样做是否正确取决于您所说的“客户”是什么意思。如果客户端的意思是“前端用户”，那么我想您也计划为每个用户设置不同的主题。如果是这样，那么您需要记住每个项目 10,000 个主题的限制。如果您的意思是每个 VM 都有自己的订阅，请注意每个 VM 将接收发布到该主题的每条消息。如果您只希望一个 VM 接收每条消息，则需要在所有 VM 中使用相同的订阅。

一般来说，还要记住 Cloud Pub/Sub 具有至少一次交付语义。这意味着即使是已确认的消息也可能被重新传送，因此您确实需要准备好处理重复的消息传送。