分布式异步任务神器-Celery

最近研究了下异步任务神器-Celery，发现非常好用，可以说是高可用，假如你发出一个任务执行命令给 Celery，只要 Celery 的执行单元 (worker)
在运行，那么它一定会执行；如果执行单元 (worker) 出现故障，如断电，断网情况下，只要执行单元 (worker) 恢复运行，那么它会继续执行你已经发出的命令。这一点有很强的实用价值：假如有交易系统接到了大量交易请求，主机却挂了，但前端用户仍可以继续发交易请求，发送交易请求后，用户无需等待。待主机恢复后，已发出的交易请求可以继续执行，只不过用户收到交易确认的时间延长而已，但并不影响用户体验。

Celery 简介

它是一个异步任务调度工具，用户使用 Celery 产生任务，借用中间人来传递任务，任务执行单元从中间人那里消费任务。任务执行单元可以单机部署，也可以分布式部署，因此 Celery 是一个高可用的生产者消费者模型的异步任务队列。你可以将你的任务交给 Celery 处理，也可以让 Celery 自动按 crontab 那样去自动调度任务，然后去做其他事情，你可以随时查看任务执行的状态，也可以让 Celery 执行完成后自动把执行结果告诉你。

应用场景：

1. 高并发的请求任务。互联网已经普及，人们的衣食住行中产生的交易都可以线上进行，这就避免不了某些时间极高的并发任务请求，如公司中常见的购买理财、学生缴费，在理财产品投放市场后、开学前的一段时间，交易量猛增，确认交易时间较长，此时可以把交易请求任务交给 Celery 去异步执行，执行完再将结果返回给用户。用户提交后不需要等待，任务完成后会通知到用户（购买成功或缴费成功），提高了网站的整体吞吐量和响应时间，几乎不需要增加硬件成本即可满足高并发。

2. 定时任务。在云计算，大数据，集群等技术越来越普及，生产环境的机器也越来越多，定时任务是避免不了的，如果每台机器上运行着自己的 crontab 任务，管理起来相当麻烦，例如当进行灾备切换时，某些 crontab 任务可能需要单独手工调起，给运维人员造成极大的麻烦，有了 Celery ，你可以集中管理所有机器的定时任务，而且灾备无论何时切换，crontab 任务总能正确的执行。

3. 异步任务。 一些耗时较长的操作，比如 I/O 操作，网络请求，可以交给 Celery 去异步执行，用户提交后可以做其他事情，当任务完成后将结果返回用户即可，可提高用户体验。

Celery 的优点

1. 纯 Python 编写，开源。这已经是站在巨人的肩膀上了，虽然 Celery 是由纯 Python 编写的，但协议可以用任何语言实现。迄今，已有 Ruby 实现的 RCelery 、node.js 实现的 node-celery 以及一个 PHP 客户端 ，语言互通也可以通过 using webhooks 实现。

2. 灵活的配置。默认的配置已经满足绝大多数需求，因此你不需要编写配置文件基本就可以使用，当然如果有个性化地定制，你可以选择使用配置文件，也可以将配置写在源代码文件里。

3. 方便监控。任务的所有状态，均在你的掌握之下。

4. 完善的错误处理。

5. 灵活的任务队列和任务路由。你可以非常方便地将一个任务运行在你指定的队列上，这叫任务路由。

Celery 的架构

学习一个工具，最好先从它的架构理解，辅以快速入门的代码来实践，最深入的就是阅读他的源码了，下图是 Celery 的架构图。

任务生产者 ：调用Celery提供的API，函数，装饰器而产生任务并交给任务队列的都是任务生产者。

任务调度 Beat：Celery Beat进程会读取配置文件的内容，周期性的将配置中到期需要执行的任务发送给任务队列

中间人（Broker）：Celery 用消息通信，通常使用中间人（Broker）在客户端和 worker 之前传递，这个过程从客户端向队列添加消息开始，之后中间人把消息派送给 worker。官方给出的实现Broker的工具有：

名称	状态	监视	远程控制
RabbitMQ	稳定	是	是
Redis	稳定	是	是
Mongo DB	实验性	是	是
Beanstalk	实验性	否	否
Amazon SQS	实验性	否	否
Couch DB	实验性	否	否
Zookeeper	实验性	否	否
Django DB	实验性	否	否
SQLAlchemy	实验性	否	否
Iron MQ	第三方	否	否

在实际使用中我们选择 RabbitMQ 或 Redis 作为中间人即可。

执行单元 worker：worker 是任务执行单元，是属于任务队列的消费者，它持续地监控任务队列，当队列中有新地任务时，它便取出来执行。worker 可以运行在不同的机器上，只要它指向同一个中间人即可，worker还可以监控一个或多个任务队列， Celery 是分布式任务队列的重要原因就在于 worker 可以分布在多台主机中运行。修改配置文件后不需要重启 worker，它会自动生效。

任务结果存储backend：用来持久存储 Worker 执行任务的结果，Celery支持不同的方式存储任务的结果，包括AMQP，Redis，memcached，MongoDb，SQLAlchemy等。

Celery 的使用示例：

以 Python3.6.5 版本为例。

1. 安装 python 库：celery，redis。

pip install celery #安装celery 
pip install celery[librabbitmq,redis,auth,msgpack] #安装celery对应的依赖

celery其他的依赖包如下：
序列化：
celery[auth]：使用auth序列化。
celery[msgpack]：使用msgpack序列化。
celery[yaml]：使用yaml序列化。
并发：
celery[eventlet]：使用eventlet池。
celery[gevent]：使用gevent池。
celery[threads]：使用线程池。
传输和后端：
celery[librabbitmq]：使用librabbitmq的C库.
celery[redis]：使用Redis作为消息传输方式或结果后端。
celery[mongodb]：使用MongoDB作为消息传输方式（实验性），或是结果后端（已支持）。
celery[sqs]：使用AmazonSQS作为消息传输方式（实验性）。
celery[memcache]：使用memcache作为结果后端。
celery[cassandra]：使用ApacheCassandra作为结果后端。
celery[couchdb]：使用CouchDB作为消息传输方式（实验性）。
celery[couchbase]：使用CouchBase作为结果后端。
celery[beanstalk]：使用Beanstalk作为消息传输方式（实验性）。
celery[zookeeper]：使用Zookeeper作为消息传输方式。
celery[zeromq]：使用ZeroMQ作为消息传输方式（实验性）。
celery[sqlalchemy]：使用SQLAlchemy作为消息传输方式（实验性），或作为结果后端（已支持）。
celery[pyro]：使用Pyro4消息传输方式（实验性）。
celery[slmq]：使用SoftLayerMessageQueue传输（实验性