Broker介绍
Broker概览
这个表格对比了不同传输方式，更多信息请参考每种方式的独立介绍文档。
| 名称 | 状态 | 有无监控 | 支持远程控制 |
|---|---|---|---|
| RabbitMQ | 稳定支持 | 有 | 是 |
| Redis | 稳定支持 | 有 | 是 |
| Amazon SQS | 稳定支持 | 无 | 否 |
| Zookeeper | 试验性支持 | 无 | 否 |
试验性支持代表也许可以运行，但没有专门的维护人员 。
没有监控代表配套的如插件Flower, celery events, celerymon等基于事件监听的监控工具无法使用。
远程控制表示使用celery inspect或者celery control命令或其他工具运行时发现和管理workers的能力。
主要内容
注意：这部分只列举了一部分支持的backends 和 brokers。
Celery能够借助很多不同的backends（结果存储）和Brokers（消息传输）来搭建服务。
Redis
Redis既可以充当backend，也能充当broker。
当作Broker：Redis非常适合传输短消息，但不适用于长消息。详情参照文档。
当作Backend：Redis 是一个非常快的KV存储，它可以十分高效的存取任务结果。但由于它的实现原理，你需要考虑容量限制的问题，以及结果持久化。如果结果持久化很重要，不建议使用redis。
RabbitMQ
RabbitMQ可以用作broker。
作为Broker：在长消息方面，RabbitMQ更有优势，但如果消息来的非常快，拥有水平扩容能力的Redis或者SQS更有优势。详情参照文档。
作为Backend：RabbitMQ也能通过 npc://backend存储信息，这种方式用于为每个客户端创建单独的临时队列。
注意：RabbitMQ（作为Broker）和Redis（作为Backend）是非常常见的一种组合；如果结果存储需要更有保证的长期持久性，考虑使用PostgreSQL或MySQL（通过SQLAlchemy）， Cassandra或自定义Backend。
SQS
SQS用作Broker。
如果你已经集成了AWS，并且非常熟悉SQS，那么它将是一个非常合适的Broker选型。它具有极强的可扩展性和完全可管理性，并且拥有RabbitMQ类似地管理任务委派功能。但它缺少RabbitMQ的一些特性，比如worker远程控制命令。
SQLAlchemy
SQLAlchemy用作Backend。
它允许Celery集成MySQL、PostgreSQL、SQlite等ORM，使用SQL DB作为Backend。