celery、rabbitmq的使用

Celery是一个专注于实时处理和任务调度的分布式任务队列。所谓任务就是消息,消息中的有效载荷中包含要执行任务需要的全部数据。

使用Celery的常见场景如下:

1. Web应用。当用户触发的一个操作需要较长时间才能执行完成时,可以把它作为任务交给Celery去异步执行,执行完再返回给用户。这段时间用户不需要等待,提高了网站的整体吞吐量和响应时间。

2. 定时任务。生产环境经常会跑一些定时任务。假如你有上千台的服务器、上千种任务,定时任务的管理很困难,Celery可以帮助我们快速在不同的机器设定不同种任务。

3. 同步完成的附加工作都可以异步完成。比如发送短信/邮件、推送消息、清理/设置缓存等。

Celery还提供了如下的特性:

1. 方便地查看定时任务的执行情况,比如执行是否成功、当前状态、执行任务花费的时间等。

2. 可以使用功能齐备的管理后台或者命令行添加、更新、删除任务。

3. 方便把任务和配置管理相关联。

4. 可选多进程、Eventlet和Gevent三种模式并发执行。

5. 提供错误处理机制。

- 提供多种任务原语,方便实现任务分组、拆分和调用链。

- 支持多种消息代理和存储后端。

Celery的架构

Celery包含如下组件:

1. Celery Beat:任务调度器,Beat进程会读取配置文件的内容,周期性地将配置中到期需要执行的任务发送给任务队列。

2. Celery Worker:执行任务的消费者,通常会在多台服务器运行多个消费者来提高执行效率。

3. Broker:消息代理,或者叫作消息中间件,接受任务生产者发送过来的任务消息,存进队列再按序分发给任务消费方(通常是消息队列或者数据库)。

4. Producer:调用了Celery提供的API、函数或者装饰器而产生任务并交给任务队列处理的都是任务生产者。

5. Result Backend:任务处理完后保存状态信息和结果,以供查询。Celery默认已支持Redis、RabbitMQ、MongoDB、Django ORM、SQLAlchemy等方式。

Celery的架构图如图所示:

选择消息代理

Celery目前支持RabbitMQ、Redis、MongoDB、Beanstalk、SQLAlchemy、Zookeeper等作为消息代理,但适用于生产环境的只有RabbitMQ和Redis,至于其他的方式,一是支持有限,二是可能得不到更好的技术支持。

Celery官方推荐的是RabbitMQ,Celery的作者Ask Solem Hoel最初在VMware就是为RabbitMQ工作的,Celery最初的设计就是基于RabbitMQ,所以使用RabbitMQ会非常稳定,成功案例很多。如果使用Redis,则需要能接受发生突然断电之类的问题造成Redis突然终止后的数据丢失等后果。

Celery序列化

在客户端和消费者之间传输数据需要序列化和反序列化,Celery支持如表9.2所示的序列化方案:

为了提供更高的性能,我们选择如下方案:

1. 选择RabbitMQ作为消息代理。

2. RabbitMQ的Python客户端选择librabbitmq这个C库。

3. 选择Msgpack做序列化。

4. 选择Redis做结果存储。

下面先安装它们。Celery提供bundles的方式,也就是安装Celery的同时可以一起安装多种依赖:

❯ pip install "celery[librabbitmq,redis,msgpack]"

注:bundles的原理是在setup.py的setup函数中添加extras_require。

从一个简单的例子开始

先演示一个简单的项目让Celery运行起来。项目的目录结构如下:

❯ tree chapter9/section3/proj

├── celeryconfig.py

├── celery.py

├── __init__.py

└── tasks.py

先看一下主程序celery.py:

from __future__ import absolute_import

from celery import Celery

app = Celery('proj', include=['proj.tasks'])

app.config_from_object('proj.celeryconfig')


if __name__ == '__main__':

    app.start()

  

解析一下这个程序:

1. "from __future__ import absolute_import"是拒绝隐式引入,因为celery.py的名字和celery的包名冲突,需要使用这条语句让程序正确地运行。

2. app是Celery类的实例,创建的时候添加了proj.tasks这个模块,也就是包含了proj/tasks.py这个文件。

3. 把Celery配置存放进proj/celeryconfig.py文件,使用app.config_from_object加载配置。

看一下存放任务函数的文件tasks.py:

from __future__ import absolute_import

from proj.celery import app


@app.task

def add(x, y):

    return x + y

  

tasks.py只有一个任务函数add,让它生效的最直接的方法就是添加app.task这个装饰器。

看一下我们的配置文件celeryconfig.py:

BROKER_URL = 'amqp://dongwm:123456@localhost:5672/web_develop' # 使用RabbitMQ作为消息代理

CELERY_RESULT_BACKEND = 'redis://localhost:6379/0' # 把任务结果存在了Redis

CELERY_TASK_SERIALIZER = 'msgpack' # 任务序列化和反序列化使用msgpack方案

CELERY_RESULT_SERIALIZER = 'json' # 读取任务结果一般性能要求不高,所以使用了可读性更好的JSON

CELERY_TASK_RESULT_EXPIRES = 60 * 60 * 24 # 任务过期时间,不建议直接写86400,应该让这样的magic数字表述更明显

CELERY_ACCEPT_CONTENT = ['json', 'msgpack'] # 指定接受的内容类型

  这个例子中没有任务调度相关的内容, 所以只需要启动消费者:

❯ cd ~/web_develop/chapter9/section3

❯ celery -A proj worker -l info

  -A参数默认会寻找proj.celery这个模块,其实使用celery作为模块文件名字不怎么合理。可以使用其他名字。举个例子,假如是proj/app.py,可以使用如下命令启动:

❯ celery -A proj.app worker -l info

  

上述信息提供了一些有帮助的内容,如消息代理和存储结果的地址、并发数量、任务列表、交换类型等。在对Celery不熟悉的时候可以通过如上信息判断设置和修改是否已生效。

 

现在开启另外一个终端,用IPython调用add函数:

In : from proj.tasks import add

In : r = add.delay(1, 3)

In : r

Out: <AsyncResult: 93288a00-94ee-4727-b815-53dc3474cf3f>

In : r.result

Out: 4

In : r.status

Out: u'SUCCESS'
In : r.successful()

Out: True

In : r.backend

Out: <celery.backends.redis.RedisBackend at 0x7fb2529500d0> # 保存在Redis中

  可以看到worker的终端上显示执行了任务:

[2016-06-03 13:34:40,749: INFO/MainProcess] Received task: proj.tasks.add[93288a00-94ee-4727-b815-53dc3474cf3f]

[2016-06-03 13:34:40,755: INFO/MainProcess] Task proj.tasks.add[93288a00-94ee-4727-b815-53dc3474cf3f] succeeded in 0.00511166098295s: 4

  通过IPython触发的任务就完成了。任务的结果都需要根据上面提到的task_id获得,我们还可以用如下两种方式随时找到这个结果:

task_id = '93288a00-94ee-4727-b815-53dc3474cf3f'

In : add.AsyncResult(task_id).get()

Out: 4

  或者:

In : from celery.result import AsyncResult

In : AsyncResult(task_id).get()

Out: 4

  

指定队列

Celery非常容易设置和运行,通常它会使用默认的名为celery的队列(可以通过CELERY_DEFAULT_QUEUE修改)用来存放任务。我们可以使用优先级不同的队列来确保高优先级的任务不需要等待就得到响应。

基于proj目录下的源码,我们创建一个projq目录,并对projq/celeryconfig.py添加如下配置:

from kombu import Queue

CELERY_QUEUES = ( # 定义任务队列

Queue('default', routing_key='task.#'), # 路由键以“task.”开头的消息都进default队列

Queue('web_tasks', routing_key='web.#'), # 路由键以“web.”开头的消息都进web_tasks队列

)

CELERY_DEFAULT_EXCHANGE = 'tasks' # 默认的交换机名字为tasks

CELERY_DEFAULT_EXCHANGE_TYPE = 'topic' # 默认的交换类型是topic

CELERY_DEFAULT_ROUTING_KEY = 'task.default' # 默认的路由键是task.default,这个路由键符合上面的default队列

CELERY_ROUTES = {

    'projq.tasks.add': { # tasks.add的消息会进入web_tasks队列

    'queue': 'web_tasks',

    'routing_key': 'web.add',

    }

}

  现在用指定队列的方式启动消费者进程:

❯ celery -A projq worker -Q web_tasks -l info

  

上述worker只会执行web\_tasks中的任务,我们可以合理安排消费者数量,让web_tasks中任务的优先级更高。

使用任务调度

之前的例子都是由发布者触发的,本节展示一下使用Celery的Beat进程自动生成任务。基于proj目录下的源码,创建一个projb目录,对projb/celeryconfig.py添加如下配置:

CELERYBEAT_SCHEDULE = {

    'add': {

        'task': 'projb.tasks.add',

       'schedule': timedelta(seconds=10),

       'args': (16, 16)

    }
}

  

CELERYBEAT_SCHEDULE中指定了tasks.add这个任务每10秒跑一次,执行的时候的参数是16和16。

启动Beat程序:

❯ celery beat -A projb

  然后启动Worker进程:

❯ celery -A projb worker -l info

  

之后可以看到每10秒都会自动执行一次tasks.add。

注:Beat和Worker进程可以一并启动:

❯ celery -B -A projb worker -l info

  

使用Django可以通过django-celery实现在管理后台创建、删除、更新任务,是因为它使用了自定义的调度类djcelery.schedulers.DatabaseScheduler,我们可以参考它实现Flask或者其他Web框架的管理后台来完成同样的功能。使用自定义调度类还可以实现动态添加任务。

任务绑定、记录日志和重试

任务绑定、记录日志和重试是Celery常用的3个高级属性。现在修改proj/tasks.py文件,添加div函数用于演示:

from celery.utils.log import get_task_logger                                                     
                                                                                                 
logger = get_task_logger(__name__)                                                               
                                                                                                 
                                                                                                 
@app.task(bind=True)                                                                             
def div(self, x, y):                                                                             
    logger.info(('Executing task id {0.id}, args: {0.args!r} '                                   
                 'kwargs: {0.kwargs!r}').format(self.request))                                   
    try:                                                                                         
        result = x / y                                                                           
    except ZeroDivisionError as e:                                                               
        raise self.retry(exc=e, countdown=5, max_retries=3)                                      
    return result

  

当使用bind = True后,函数的参数发生变化,多出了参数self(第一个参数),相当于把div变成了一个已绑定的方法,通过self可以获得任务的上下文。

在IPython中调用div:

In : from proj.tasks import div

In : r = div.delay(2, 1)

  可以看到如下执行信息:

[2016-06-03 15:50:31,853: INFO/Worker-1] proj.tasks.div[1da82fb8-20de-4d5a-9b48-045da6db0cda]: Executing task id 1da82fb8-20de-4d5a-9b48-045da6db0cda, args: [2, 1] kwargs: {}

  换成能造成异常的参数:

In : r = div.delay(2, 0)

  可以发现每5秒就会重试一次,一共重试3次(默认重复3次),然后抛出异常。

 

原文链接

 

 

 

最近同事项目想使用celery与rabbitmq来做任务调度,让我做一次这方面的使用分享。工作之余大致整理了一下。

一、先介绍一下rabbitmq消息队列

 
 
•AMQP,即AdvancedMessage Queuing Protocol,高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。消息中间件主要用于组件之间的解耦,消息的发送者无需知道消息使用者的存在,反之亦然。
•AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。
•RabbitMQ是一个开源的AMQP实现,服务器端用Erlang语言编写,支持多种客户端,如:Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等,支持AJAX。用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面表现不俗
 

1、queue、channel

•Queue(队列)是RabbitMQ的内部对象,用于存储消息。
•Channel是我们与RabbitMQ打交道的最重要的一个接口,我们大部分的业务操作是在Channel这个接口中完成的,包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等。

2、exchange

•生产者不是将消息直接放到queue(队列)中,而是先到exchange中,exchange主要用于控制消息到队列的路由,根据具体的exchange type将消息传给需要的队列或者直接废弃。
•RabbitMQ常用的ExchangeType有fanout、direct、topic、headers这四种,不同的类型有着不同的路由策略。
 
(1)fanout-exchange:  fanout类型的Exchange路由规则非常简单,它会把所有发送到该Exchange的消息路由到所有与它绑定的Queue中;
 
(2)direct-exchange:direct类型的Exchange路由规则也很简单,它会把消息路由到那些bindingkey与routingkey完全匹配的Queue中;
 
(3)topic-exchange:前面讲到direct类型的Exchange路由规则是完全匹配bindingkey与routingkey,但这种严格的匹配方式在很多情况下不能满足实际业务需求。topic类型的Exchange在匹配规则上进行了扩展,它与direct类型的Exchage相似,也是将消息路由到bindingkey与routingkey相匹配的Queue中,但这里的匹配规则有些不同,它约定:

(1)routing key为一个句点号“.”分隔的字符串(我们将被句点号     “. ”分隔开的每一段独立的字符串称为一个单词),如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”

(2)binding key与routingkey一样也是句点号“.”分隔的字符串

(3)binding key中可以存在两种特殊字符“*”与“#”,用于做模糊匹配,    其中“*”用于匹配一个单词,“#”用于匹配多个单词(可以是零个)

 

二、下面介绍一下celery及使用:

 Celery是基于Python开发的分布式任务队列。它支持使用任务队列的方式在分布的机器/进程/线程上执行任务调度。


1、 celery工作流程:

    

  消息中间件(message broker):Celery本身不提供消息服务,但是可以方便的和第三方提供的消息中间件集成。包括,RabbitMQRedisMongoDB ,SQLAlchemy等,其中rabbitm与redis比较稳定,其他处于测试阶段。

 任务执行单元(worker):Worker是Celery提供的任务执行的单元,worker并发的运行在分布式的系统节点中。

 任务结果存储(result store):result store用来存储Worker执行的任务的结果,支持AMQP,redis,mongodb,mysql等主流数据库。

2、并发、序列化、压缩:

 celery任务并发执行支持prefork、eventlet、gevent、threads的方式;

 序列化支持pickle,json,yaml,msgpack等;

 压缩支持zlib, bzip2 。

3、celery使用中的一些建议和优化

这里主要说一下celery使用中的一些优化,关于app、task、worker、queue、router等等大家可以参照官方文档:http://docs.celeryproject.org/en/latest/

(1)、如果你的broker使用的是rabbitmq,可安装一个C语言版的客户端librabbitmq来提升性能, pip install librabbitmq

(2)、通过 BROKER_POOL_LIMIT 参数配置消息中间件的连接池;

(3)、通过CELERYD_PREFETCH_MULTIPLIER 参数配置消息预取的数量,如果消息队列中有很多消息,这个值建议设为1,以达到各个worker的最大化利用;

(4)、指定worker消费的队列,如果你根据业务配置了多个不同的消息队列,各个队列的任务量大小不同,可以在worker启动时指定消费队列  celery -A app_name -l INFO -Q queue1,queue2

(5)、worke(prefork)默认启动cpu核数个子进程,进程管理可以使用supervisor,supervisor是用Python开发的一套通用的进程管理程序,能将一个普通的命令行进程变为后台daemon,并监控进程状态,异常退出时能自动重启

 

原文:http://blog.csdn.net/nxgych/article/details/53127472

posted @ 2018-02-20 10:10  dion至君  阅读(1785)  评论(0编辑  收藏  举报