分布式任务框架之celery

架构

• 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监控管理

添加管理任务

任务的监控

celery的魅力

• 高可用

1. 对于celery worker来说，其实部署在多个节点上，就是高可用的。
2. 对于borker来说，我们使用了rabbitmq集群来保证高可用（我们线上同时也有其他celery服务使用了AWS的SQS作为borker，其本身就是保证高可用的）。
3. 对于celerybeat（就是启动定时任务的程序）来说，只能使用单节点启动，很难保证高可用，但是我们这边线上，并没有使用celerybeat来启动celery定时任务，而是使用了第三方服务（AWS lambda）来发送定时任务到celery borker中（相当于实现了celerybeat功能），这样就用第三方的这个服务保证高可用。
   其实除了使用AWS lambda的这种方案，我们还使用了在docker集群中部署celerybeat的方案，这种其实也是能保证celerybeat的高可用的

参考文献：

1. Celery+RabbitMQ的多机器worker节点介绍
2. celery有什么难理解的