后端和经纪人

Celery 支持多种消息传输替代方案。

经纪人说明

这是不同传输支持的比较表，可以在每个单独传输的文档中找到更多信息（请参阅代理说明）。

实验性经纪人可能是功能性的，但他们没有专门的维护者。

缺少监视器支持意味着传输不实现事件，因此 Flower、celery events、celerymon 和其他基于事件的监视工具将无法工作。

远程控制意味着能够在运行时使用 celery inspect 和 celery control 命令（以及使用远程控制 API 的其他工具）检查和管理工作人员。

注意：本节不全面介绍后端和代理。

Celery 能够与许多不同的后端（结果存储）和代理（消息传输）进行通信和存储。

Redis 既可以是后端，也可以是代理。

作为Broker：Redis 非常适合快速传输小消息。大消息会使系统拥塞。

作为后端：Redis 是一个超快的 K/V 存储，使得它非常有效地获取任务调用的结果。与 Redis 的设计一样，您必须考虑可用于存储数据的内存限制，以及如何处理数据持久性。如果结果持久性很重要，请考虑为您的后端使用另一个数据库。

RabbitMQ 是一个代理。

作为经纪人： RabbitMQ 处理更大的消息比 Redis 更好，但是如果许多消息非常快地传入，扩展可能会成为一个问题，除非 RabbitMQ 以非常大的规模运行，否则应该考虑 Redis 或 SQS。

作为后端： RabbitMQ 可以通过 rpc:// 后端存储结果。此后端为每个客户端创建单独的临时队列。

注意：RabbitMQ（作为broker）和Redis（作为后端）经常一起使用。如果结果存储需要更有保证的长期持久性，请考虑使用 PostgreSQL 或 MySQL（通过 SQLAlchemy）、Cassandra 或自定义定义的后端。

SQS 是经纪人。

如果您已经与 AWS 紧密集成，并且熟悉 SQS，那么它作为代理是一个不错的选择。它具有极强的可扩展性和完全托管性，并且与 RabbitMQ 类似地管理任务委派。它确实缺少 RabbitMQ 代理的一些功能，例如 worker remote control commands。

SQLAlchemy 是后端。

它允许 Celery 与 MySQL、PostgreSQL、SQlite 等接口。它是一个 ORM，也是 Celery 可以使用 SQL DB 作为结果后端的方式。从历史上看，SQLAlchemy 并不是最稳定的结果后端，所以如果选择一个应该谨慎行事。