用于异步 REST 中状态更新的 RabbitMQ 临时队列

Question

我正在设计一个 REST API，它根据此处详细介绍的异步设计工作。我正在使用 RabbitMQ 对初始请求进行排队 - 因此客户端发出调用，接收响应202 Accepted，并且作业由服务器排队。为了使客户端可以获得任务的状态更新（“完成百分比”），我们有一个辅助队列资源，就像链接的文章中一样。

鉴于每个任务都有自己的队列资源，似乎每个任务都需要一个临时 RabbitMQ 队列。我想知道这是否是一个明智的设计选择，尽管我看不到任何其他选择。这似乎不太高效，而且我对像这样创建大量临时队列的可能性感到不安，特别是因为我看不到一种方法来保证它们全部被清理（尽管 RabbitMQ 具有自动删除功能） 。在使用 RabbitMQ 之前，我使用 SQS 来实现此目的，并且对这方面可能发生的情况有痛苦的经验。

我注意到，对于那些使用 RPC 风格的 RabbitMQ 的人来说，类似类型的队列管理已经很熟悉了。然而，还有可能的替代方案吗？

Answer 1

首先，每个队列都使用 apr。20k 内存，因此拥有多少内存取决于您和您的硬件。但总体来说还是有味道的。真的。

对于状态更新，我认为使用某些键值数据库（例如 redis 甚至 memcache）并在那里完成更新百分比没有任何问题。因此，状态检查（以及更新）将非常快速、简单且轻量。

更新：

我可以建议进一步的架构：

1. 客户端POST任务有效负载到某个端点，例如/tasks。
2. 应用程序生成唯一的任务 id（uuid 又名 guid 是你的朋友），将该任务及其 id 发布到 RabbitMQ 队列，然后将 id 返回给客户端。
3. 工作人员（一个或多个）使用来自 RabbitMQ 的任务，并依赖于处理步骤更新 Redis 键，该键具有带有某个值的任务 ID（步骤、完成百分比、接收结果的预计时间）。所以，它可能看起来像SET task:{id} "<some valye>"。当工作人员完成任务时，它可以使用任务结果更新 Redis 键或将其存储在其他位置，然后设置 Redis 键表示任务已完成。
4. 客户可以不时GET /tasks/{id}接收任务状态或其结果。
5. 当应用程序接收到GET /tasks/{id}它时，它返回由 Redis key ( ) 表示的任务状态GET task:{id}。如果 key 没有设置 ( nil) 那么任务还没有被worker接受。

聚苯乙烯

RPC 与您所问的有所不同，但我建议您阅读此问题以了解一些详细信息。