4

我最喜欢 Google 的任务队列的特点之一是它的简单性。更具体地说，我喜欢它接受一个 URL 和一些参数，然后在任务队列准备好执行任务时发布到该 URL。

这种结构意味着任务总是执行最新版本的代码。相反，我的 gearman 工作人员都在我的 django 项目中运行代码——所以当我实时推送新版本时，我必须杀死旧工作人员并运行一个新工作人员，以便它使用当前版本的代码。

我的目标是让任务队列独立于代码库，这样我就可以在不重新启动任何工作人员的情况下推送新的实时版本。所以，我开始思考：为什么不让任务像谷歌应用引擎任务队列一样通过 url 执行？

该过程将像这样工作：

  1. 用户请求进来并触发了一些不应阻塞的任务。
  2. 每个任务都有一个唯一的 URL，因此我将一个 gearman 任务排入队列以 POST 到指定的 URL。
  3. gearman 服务器找到一个 worker，将 url 和 post 数据传递给一个 worker
  4. 工作人员只需将数据发布到 url，从而执行任务。

假设如下：

  1. 来自 gearman worker 的每个请求都以某种方式签名，以便我们知道它来自 gearman 服务器而不是恶意请求。
  2. 任务被限制在 10 秒内运行（不会有可能超时的长任务）

这种方法的潜在缺陷是什么？这是我担心的一个：

  • 服务器可能会同时受到许多由先前请求触发的请求的冲击。因此，一个用户请求可能需要 10 个并发 http 请求。我想我可以在每次请求限速之前让一个工作人员睡觉。

有什么想法吗？

4

1 回答 1

4

作为 Django 和 Google AppEngine 的用户，我当然可以理解您的理解。在工作中，我目前正在使用一些非常酷的开源工具处理完全相同的场景。

  1. 看看芹菜。它是一个用 Python 构建的分布式任务队列，它公开了三个概念——队列、一组工作人员和一个结果存储。每个部分都可以使用不同的工具进行插拔。

  2. 队列应该是久经沙场的，而且速度很快。查看RabbitMQ，了解 Erlang 中使用 AMQP 协议的出色队列实现。

  3. 工人最终可以是 Python 函数。您可以使用队列消息触发工作人员，或者可能与您所描述的内容更相关 - 使用webhook

查看Celery webhook文档。使用所有这些工具，您可以构建一个满足上述要求的生产就绪分布式任务队列。

我还应该提到，关于您的第一个陷阱，celery 使用令牌桶算法实现任务的速率限制。

于 2010-03-31T19:33:42.817 回答