django: celery vs channel vs in-view

Question

假设我的页面上有一个按钮，单击该按钮会触发对我的 api 端点的 ajax 请求，然后从 3rd 方站点获取数据。假设这个任务大约需要 2-5 秒，超时时间为 5 秒。这样做的理想方法是什么:

api 端点中的 celery task.delay() 并返回一个 url 以每隔 x 间隔轮询结果。

只需在 View 中执行

我见过的所有教程都建议使用 celery 方式，但这对于一个处理最少的简单请求来说似乎需要很多机器/开销。是否有一些普遍接受的阈值(直到完成的秒数等)，其中一个会选择一个而不是另一个？

然后是 django-channels，这似乎是理想的选择。但是，乍一看， channel worker 和 celery 任务之间的区别似乎很模糊。我可以用 channel worker 替换 celery 并将其用于上述任务吗？ channel 也会处理我运行时间较长的任务吗？使用 channel (使用 celery 或替换 celery)有什么优点/缺点？

最后，对于给出的示例场景，这 3 个(celery/channels/in-view)中的哪一个是推荐的方法？

Answer 1

我不是 channel 专家，但我们开始吧。

Channels 是 WSGI(新协议(protocol)是 ASGI)之上的一个抽象，它允许您通过“抽象” channel 进行通信。有时你会做 HTTP，有时是 websockets，有时是你可以做几乎任何通信模式的其他东西。

Celery 以类似的方式构建，它使用消息总线(有时是更复杂的代理机制，具体取决于您的运行方式)将工作发送到可以发送回可选结果的工作机器。

现在你选择哪个？

在 View 中

除非您有专门为此目的设计的 View ，否则我会避免这种情况。您需要确保您的堆栈可以处理长期连接(例如，如果需要超过 30 秒，heroku 的路由器会提示)，或者您需要实现一些长轮询接口(interface)。

用 celery

您需要完成所有设置才能使内容联机。

拥有一个您想要其结果的任务将需要一个结果后端并传递任务 ID。

您需要实现一个可以查询 celery 的 View ，以确定任务在完成、成功等方面的位置。

例如。

# kick of the task somewhere

def create_task(request, *args, **kwargs):
    task_id = some_task.delay(param)
    return Response({'task_id': task_id})

网址.py

url(r'^/tasks/<task_id>/$', name='task-progress')

View .py

def task_progress_view(request, task_id):
    # get fancier here, this is just an example
    return Response(some_task.AsyncResult(task_id).state)

这是一个非常简单的例子，但应该作为一个起点。

有 channel

您需要设置总线，以与 celery 基本相同的方式将所需的 View 集中在一起，只是您仍然需要一段代码通过重试、超时逻辑等来获取数据。

选择什么

Celery 将负责工作部分，您必须负责更新并通知您的客户。 channel 将是处理后退和第四次的合理方式，但您可能不需要它。

我会考虑你还需要做什么。大多数应用程序在某些时候需要异步工作，因为业务逻辑经常要求它。如果您打算使用 websockets 等，但您不想将您的 django 应用程序分解为服务，我会硬着头皮做这两件事。

如果您不需要多个通信协议(protocol)，只需使用 celery 并执行 View 即可。