分布式任务框架之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有什么难理解的