谷歌 PubSub 存在拉式订阅者设计缺陷？

Question

我们使用googles steaming pull订阅者设计如下

我们正在做

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

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

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

注意

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

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

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

编辑：
删除代码示例

Answer 1

我会说这个设计有几个部分是次优的。首先，在您完成处理之前确认消息意味着您冒着消息丢失的风险。如果您的工具或订阅者在确认消息后但在处理完成之前崩溃了怎么办？这意味着当进程重新启动时，它们将不会再次收到消息。你对来自前端的请求可能永远不会被处理还好吗？如果没有，您将需要在处理完成后确认，或者 - 鉴于您的处理需要很长时间 - 将请求保留到数据库或某些存储，然后确认消息。如果您无论如何都必须将文件保存在其他地方，您可能需要考虑将 Pub/Sub 排除在外，然后将文件写入 GCS 等存储，然后让您的订阅者直接从 GCS 中读取。

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

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

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

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