架构Broker消息代理，作为临时储存任务的中间媒介，为 Celery 提供了队列服务。生产者将任务发送到 Broker，消费者再从 Broker 获取任务。Celery目前支持RabbitMQ、Redis、MongoDB、Beanstalk、SQLAlchemy、Zookeeper等 作为消息代理，但适用于生产环境的只有RabbitMQ和Redis，至于其他的方式，一是支持有限， 二是可能得不到更好的技术支持。 Celery官方推荐的是RabbitMQ，Celery的作者Ask Solem Hoel最初在VMware就是为RabbitMQ工作的，Celer最初的设计就是基于RabbitMQ，所以使用 RabbitMQ会非常稳定，成功案例很多。如果使用Redis，则有可能发生突然断电之类的问题 造成Redis突然终止后的数据丢失等后果。Beat任务调度器，负责调度并触发 Celery 定时周期任务。Beat 进程读取 CeleryConfig 中自定义的定时周期任务列表，将到期需要执行的定时任务发送到任务队列中。Worker任务执行单元，实际负责执行任务的服务进程，每一个 Worker 都有一个并发池（Prefork/Eventlet/Gevent/Thread）来支持多并发。Worker 会监听订阅的任务队列，当队列中有任务时，就会获取任务并执行。Result Backend/Store任务执行状态和结果存储，Celery 支持任务实时处理，也就是说 Celery 可以把任务执行的实时状态和最终结果回传生产者。这种回传也需要通过中间存储媒介。web监控管理添加管理任务任务的监控