Celery 是一个专注于实时处理和任务调度的分布式任务队列。所谓任务就是消息，消息中包含要执行任务需要的全部数据。
使用 Celery 的常见场景：
Web 应用。当用户触发的一个操作需要较长时间才能执行完成时，可以把它作为任务交给Celery 去异步执行，执行完再返回给用户。这段时间用户不需要等待，提高了网站的整体吞吐量和响应时间。
定时任务。生产环境经常会跑一些定时任务。假如你有上千台的服务器、上千种任务，定时任务的管理很困难，Celery 可以帮助我们快速在不同的机器设定不同种任务。
其他可以异步执行的任务。为了充分提高网站性能，对于请求和响应之外的那些不要求必须同步完成的附加工作都可以异步完成。比如发送短信/邮件、推送消息等。
Celery 特性：
方便地查看定时任务的执行情况，比如执行是否成功、当前状态、执行任务花费的时间等。
可以使用功能齐备的管理后台或者命令行添加、更新、删除任务。
Celery 架构（包含如下组件）：
Celery Beat：任务调度器，Beat 进程会读取配置文件的内容，周期性地将配置中到期需要执行的任务发送给任务队列。
Celery Worker：执行任务的消费者，通常会在多台服务器运行多个消费者来提高执行效率。
Broker：消息代理，或者叫作消息中间件，接受任务生产者发送过来的任务消息，存进队列再按序分发给任务消费者。由于 Celery 本身不含消息服务，所以需要使用第三方消息服务来传递任务。目前，Celery 支持的消息服务有RabbitMQ、Redis甚至是数据库。
Producer：调用了 Celery 提供的 API、函数或者装饰器而产生任务并交给任务队列处理的都是任务的生产者。
Result Backend：任务处理完成后保存状态信息和结果，以供查询。
关于选择消息代理
Celery 目前支持 RabbitMQ、Redis、MongoDB、SQLAlchemy、Zookeeper 等作为消息代理，但适用于生产环境的只有 RabbitMQ 和 Redis，至于其他的方式，一是支持有限，二是可能得不到更好的技术支持。
Celery 官方推荐的是 RabbitMQ，Celery 最初的设计就是基于 RabbitMQ，所以使用 RabbitMQ 会非常稳定。如果使用 Redis，则需要能接受发生突然断电之类的问题造成 Redis 突然终止后的数据丢失等后果。
Celery 序列化
在客户端和消费者之间传输数据需要序列化和反序列化，Celery 支持如下序列化方案。
