时间戳

首页 > 解决方案 > 处理分布式长期任务的 pubsub 订阅者

redis - 处理分布式长期任务的 pubsub 订阅者

问题描述

我正在评估将 pubsub 用于长时间运行的任务（例如视频转码）的使用，其中特定的转码可能需要 2-10 分钟。pubsub 是这种任务分配的好方法吗？例如，假设我有五台服务器：

- publisher1
- publisher2
- publisher3
- publisher4
- publisher5

还有一个叫做“视频”的话题。是否有可能在这五台服务器上平均分配消息？什么时候添加或删除服务器？什么是这样做的好方法，或者 pubsub 不是这样的正确工具？

标签： redismessage-queuepublish-subscribegoogle-cloud-pubsub

解决方案

这听起来确实像是 pubsub 的一个合理用例。具体来说，如果您使用 pull 订阅者，您可以将流控制设置配置为最多向您的服务器发送一条未完成的消息，并将 max ack 扩展周期（在 java 中）配置为处理时间的合理上限。这个 api 在这里描述http://googleapis.github.io/google-cloud-java/google-cloud-clients/apidocs/index.html?com/google/cloud/pubsub/v1/package-summary.html

如果您对所有作业使用相同的订阅者 ID，则默认情况下这应该有效地平衡您的服务器之间的负载。如果添加了服务器并且存在积压，它将收到一个新条目。如果服务器被删除，它将不再被发送消息。如果它在处理或崩溃时被删除，它正在处理的消息将被重新发送到另一台服务器。

然而，一个问题是 pubsub 的每条消息限制为 10MB。您可能会考虑将数据本身放在谷歌云存储桶中。上传完成后，云存储可以将文件位置发布到 pubsub 主题。 https://cloud.google.com/storage/docs/pubsub-notifications

推荐阅读