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

你可能感兴趣的:(定时任务,分布式,celery,python)