Celery 是否适合与许多小型分布式系统一起使用？

Question

我正在编写一些软件，它将通过间歇性3G（或类似的）连接在“现场”管理数百个small systems。

总部需要将作业发送到现场系统（例如，“报告您的状态”、“更新您的软件”等），并且现场系统需要将作业发送回服务器（例如，“检测到故障”、“这里有一些数据”等）。

我花了一些时间查看Celery，它似乎非常适合：celeryd 在基地运行可以为现场系统收集工作，@987654325在现场系统上运行的@ 可以为服务器收集作业，并且可以在客户端可用时交换这些作业。

那么，Celery 适合解决这个问题吗？具体来说：

• 大部分任务将被定向到单个工作人员（例如，“将‘get_status’作业发送到‘system51’”）——这会是个问题吗？
• 它能否优雅地处理不利的网络条件（例如，连接中断）？
• 什么功能只有在 RabbitMQ 被用作后端时才可用？ （我宁愿不在现场系统上运行 RabbitMQ）
• 如果我像我描述的那样使用芹菜，还有其他原因会让我的生活变得困难吗？

谢谢！

（认为 Celery 有点矫枉过正是有道理的，但还有其他原因可以让我的生活更轻松，所以我想考虑一下）

Answer 1

大部分任务将被定向 给单个工人（例如，“发送 ‘get_status’ 作业到 ‘system51’”) — 这会是个问题吗？

一点也不。只需为每个工作人员创建一个队列，例如假设每个节点都侦听一个名为default 的循环队列，并且每个节点都有自己的以其节点名称命名的队列：

(a)$ celeryd -n a.example.com -Q default,a.example.com
(b)$ celeryd -n b.example.com -Q default,b.example.com
(c)$ celeryd -n c.example.com -Q default,c.example.com

将任务直接路由到节点很简单：

$ get_status.apply_async(args, kwargs, queue="a.example.com")

或者通过配置使用Router:

# Always route "app.get_status" to "a.example.com"
CELERY_ROUTES = {"app.get_status": {"queue": "a.example.com"}}

它是否优雅地处理不利因素 网络条件（例如， 连接死亡）？

worker 优雅地从代理连接失败中恢复。 （至少来自 RabbitMQ，我不确定所有其他后端，但是这个 易于测试和修复（您只需将相关异常添加到列表中）

对于客户端，如果连接断开，您可以随时重试发送任务， 或者您可以使用 RabbitMQ 设置 HA：http://www.rabbitmq.com/pacemaker.html

只有哪些功能可用 如果 RabbitMQ 被用作 后端？ （我宁愿不运行 RabbitMQ 在现场系统上）

远程控制命令，仅支持“直接”交换（不支持“主题”或“扇出”）。但这将在Kombu (http://github.com/ask/kombu) 中得到支持。

我会认真重新考虑使用 RabbitMQ。为什么你认为它不适合？ 恕我直言，我不会在其他地方寻找这样的系统，（如果系统可能是 ZeroMQ 是暂时的，您不需要消息持久性）。

还有什么其他原因可以让芹菜成为我的生活 如果像我描述的那样使用它会很困难吗？

我想不出你上面描述的任何东西。由于并发模型 是多处理它确实需要一些内存（我正在努力添加对 线程池和 eventlet 池，在某些情况下可能会有所帮助）。

认为 Celery 是矫枉过正是有道理的，但也有 其他让我的生活更轻松的原因，所以我想 考虑一下）

在这种情况下，我认为您轻描淡写地使用了“矫枉过正”这个词。这真的取决于 关于没有它你需要编写多少代码和测试。我想 最好改进一个已经存在的通用解决方案，理论上听起来 喜欢它应该适用于您的应用程序。

Answer 2

我可能会设置一个 (django) 网络服务来接受请求。 Web 服务可以完成验证请求和转移错误请求的工作。然后芹菜就可以完成这项工作。

这将需要远程设备轮询 Web 服务以查看它们的工作是否已完成。这可能合适，也可能不合适，具体取决于您在做什么。