【问题标题】:Celery: long dedicated monolithic task vs short multiple tasksCelery:长时间的专用单片任务与短的多任务
【发布时间】:2012-09-06 19:38:04
【问题描述】:

在我的解决方案中,我使用分布式任务来监控硬件实例一段时间(比如 10 分钟)。我必须在以下情况下做一些事情:

  • 我开始这个监控会话
  • 我完成了这个监控会话
  • (可能)在监控会话期间

在整个会话(10 分钟)中运行单个任务并执行所有这些操作是否安全,或者我应该将这些操作拆分为它们自己的任务?

在我看来,单一任务的优势在于更容易管理和实施时序约束。但是:

运行一大群(大部分)睡着的工人是个好主意吗?例如,如果我知道我最多会打开 200 个会话,那么我有 500 名工作人员来确保始终有可用的“会话”席位?

【问题讨论】:

    标签: python rabbitmq celery distributed-computing django-celery


    【解决方案1】:

    对此没有万能的答案

    • 将大任务 A 分成许多小部分(A¹、A²、A³、...)会增加潜在的并发性。

    因此,如果您有 1 个具有 10 个工作线程/进程的工作实例, A 现在可以使用 10 个线程并行运行,而不是顺序运行 在一个线程上。

    部分的数量称为任务粒度(细粒度或粗粒度)。

    • 如果任务过于精细,消息传递的开销会拖累性能。

    每个部分必须有足够的计算/IO来抵消发送任务的开销 消息发送给代理,如果没有工作人员来接收消息,则可能将其写入磁盘,工作人员接收消息等等(请注意,可以调整消息传递开销,例如,您可以拥有一个瞬态队列(不是将消息持久化到磁盘),并发送在那里不那么重要的任务)。

    • 一个繁忙的集群可能会让所有这些都没有实际意义

    如果您有一个繁忙的集群(例如,3 个工作实例,每个实例有 10 个线程/进程,所有正在运行的任务),则可能已经实现了最大并行度。

    那么你很多人通过划分任务并没有得到太多好处,但是执行 I/O 的任务比 CPU 密集型任务(按 I/O 操作划分)有更大的改进机会。

    • 长时间运行的任务没问题

    工人对长时间运行的任务不过敏,无论是 10 分钟还是一个小时。

    但这也不理想,因为任何长时间运行的任务都会阻止该插槽 完成任何等待的任务。为了缓解这种情况,人们使用路由,这样您就有了一个专用队列,其中有专门的工作人员来处理必须尽快运行的任务。

    -

    【讨论】:

    • 感谢您的深入回答。我期待我最终会得到一个多队列解决方案。
    猜你喜欢
    • 2016-09-28
    • 1970-01-01
    • 2011-09-15
    • 2022-06-10
    • 2018-02-10
    • 2015-11-15
    • 2014-07-01
    • 1970-01-01
    • 2023-03-09
    相关资源
    最近更新 更多