【Python 分布式】 Celery：python并行框架
|
Celery 官网： Celery 官方文档： Celery 官方文档中文版： celery配置： 参考： 分布式队列神器 Celery： celery最佳实践： Celery 分布式任务队列快速入门： 异步任务神器 Celery 快速入门教程： 定时任务管理之python篇celery使用： 异步任务神器 Celery： celery任务调度框架实践： Celery-4.1 用户指南: Monitoring and Management Guide： Celery安装及使用： Celery学习笔记（一）： Celery 简介 除了redis，还可以使用另外一个神器---Celery。Celery是一个异步任务的调度工具。 Celery 是 Distributed Task Queue，分布式任务队列，分布式决定了可以有多个 worker 的存在，队列表示其是异步操作，即存在一个产生任务提出需求的工头，和一群等着被分配工作的编程之家。 在 Python 中定义 Celery 的时候，我们要引入 Broker，中文翻译过来就是“中间人”的意思，在这里 Broker 起到一个中间人的角色。在工头提出任务的时候，把所有的任务放到 Broker 里面，在 Broker 的另外一头，一群编程之家等着取出一个个任务准备着手做。 这种模式注定了整个系统会是个开环系统，工头对于编程之家们把任务做的怎样是不知情的。所以我们要引入 Backend 来保存每次任务的结果。这个 Backend 有点像我们的 Broker，也是存储任务的信息用的，只不过这里存的是那些任务的返回结果。我们可以选择只让错误执行的任务返回结果到 Backend，这样我们取回结果，便可以知道有多少任务执行失败了。 Celery()是一个异步任务队列/基于分布式消息传递的作业队列。它侧重于实时操作，但对调度支持也很好。Celery用于生产系统每天处理数以百万计的任务。Celery是用Python编写的，但该协议可以在任何语言实现。它也可以与其他语言通过webhooks实现。Celery建议的消息队列是RabbitMQ，但提供有限支持Redis, Beanstalk, MongoDB, CouchDB, 和数据库（使用SQLAlchemy的或Django的 ORM） 。Celery是易于集成Django, Pylons and Flask，使用 django-celery, celery-pylons and Flask-Celery 附加包即可。 Celery 介绍在Celery中几个基本的概念，需要先了解下，不然不知道为什么要安装下面的东西。概念：Broker、Backend。 什么是broker？ broker是一个消息传输的中间件，可以理解为一个邮箱。每当应用程序调用celery的异步任务的时候，会向broker传递消息，而后celery的worker将会取到消息，进行对于的程序执行。好吧，这个邮箱可以看成是一个消息队列。其中Broker的中文意思是 经纪人 ，其实就是一开始说的 消息队列 ，用来发送和接受消息。这个Broker有几个方案可供选择：RabbitMQ (消息队列)，（缓存数据库），（不推荐），等等 什么是backend？ 通常程序发送的消息，发完就完了，可能都不知道对方时候接受了。为此，celery实现了一个backend，用于存储这些消息以及celery执行的一些消息和结果。Backend是在Celery的配置中的一个配置项 CELERY_RESULT_BACKEND ，作用是保存结果和状态，如果你需要跟踪任务的状态，那么需要设置这一项，可以是Database backend，也可以是Cache backend，具体可以参考这里： 。 对于 brokers，官方推荐是 rabbitmq 和 redis，至于 backend，就是数据库。为了简单可以都使用 redis。 我自己演示使用RabbitMQ作为Broker，用作为backend。 来一张图，这是在网上最多的一张Celery的图了，确实描述的非常好
Celery的由三部分组成，（message broker），任务执行单元（worker）和任务执行结果存储（task result store）组成。 Celery本身不提供消息服务，但是可以方便的和第三方提供的集成。包括，RabbitMQ, , (experimental), Amazon SQS (experimental),CouchDB (experimental), SQLAlchemy (experimental),Django ORM (experimental), IronMQ 任务执行单元 Worker是Celery提供的任务执行的单元，worker并发的运行在分布式的系统节点中。 任务结果存储 Task result store用来存储Worker执行的任务的结果，Celery支持以不同方式存储任务的结果，包括AMQP, ，memcached, ，SQLAlchemy, Django ORM，Apache Cassandra, IronCache 等。 这里我先不去看它是如何存储的，就先选用redis来存储任务执行结果。 因为涉及到消息中间件（在Celery帮助文档中称呼为中间人 根据 Celery的帮助文档 安装和设置RabbitMQ, 要使用 Celery，需要创建一个 RabbitMQ 用户、一个虚拟主机，并且允许这个用户访问这个虚拟主机。 结果如下，成功运行： 安装Redis,它的安装比较简单 然后进行简单的配置，只需要设置 Redis 数据库的位置: URL的格式为： 是一个强大的 分布式任务队列 的 异步处理框架，它可以让任务的执行完全脱离主程序，甚至可以被分配到其他主机上运行。我们通常使用它来实现异步任务（async task）和定时任务（crontab）。我们需要一个消息队列来下发我们的任务。首先要有一个消息中间件，此处选择rabbitmq (也可选择 redis 或 Amazon Simple Queue Service(SQS)消息队列服务)。推荐 选择 rabbitmq 。使用RabbitMQ是官方特别推荐的方式，因此我也使用它作为我们的broker。它的组成如下图： 可以看到，Celery 主要包含以下几个模块： 任务模块 Task 包含异步任务和定时任务。其中，异步任务通常在业务逻辑中被触发并发往任务队列，而定时任务由 Celery Beat 进程周期性地将任务发往任务队列。 消息中间件 Broker Broker，即为任务调度队列，接收任务生产者发来的消息（即任务），将任务存入队列。Celery 本身不提供队列服务，官方推荐使用 RabbitMQ 和 等。 任务执行单元 Worker Worker 是执行任务的处理单元，它消息队列，获取队列中调度的任务，并执行它。 任务结果存储 Backend Backend 用于存储任务的执行结果，以供查询。同消息中间件一样，存储也可使用 RabbitMQ, 和 等。 有了上面的概念，需要安装这么几个东西：RabbitMQ、SQLAlchemy、Celery 安装rabbitmq 官网安装方法： 启动管理插件：sbin/rabbitmq-plugins enable rabbitmq_management rabbitmq已经启动，可以打开页面来看看 用户名密码都是guest 。现在可以进来了，可以看到具体页面。 关于rabbitmq的配置，网上很多 自己去搜以下就ok了。 消息中间件有了，现在该来代码了，使用 celeby官网代码。 剩下两个都是的东西了，直接pip安装就好了，对于从来没有安装过驱动的同学可能需要安装MySQL-。安装完成之后，启动服务: $ rabbitmq-server[回车]。启动后不要关闭窗口, 下面操作新建窗口(Tab)。 安装celery http://www.open-open.com/lib/view/open1441161168878.html 使用celery包含三个方面：1. 定义任务函数。2. 运行celery服务。3. 客户应用程序的调用。 创建一个文件 tasks.py输入下列代码： 上述代码导入了celery，然后创建了celery 实例 app，实例化的过程中指定了任务名tasks（和文件名一致），传入了broker和backend。然后创建了一个任务函数add。下面启动celery服务。在当前命令行终端运行（分别在 env1 和 env2 下执行）： 目录结构 （celery -A tasks worker --loglevel=info 这条命令当前工作目录必须和 tasks.py 所在的目录相同。即 进入tasks.py所在目录执行这条命令。） 使用 python 虚拟环境 两个不同的 主机。 此时会看见一对输出。包括注册的任务啦。 交互式客户端程序调用方法 打开一个命令行，进入Python环境。 调用 delay 函数即可启动 add 这个任务。这个函数的效果是发送一条消息到broker中去，这个消息包括要执行的函数、函数的参数以及其他信息，具体的可以看 Celery官方文档。这个时候 worker 会等待 broker 中的消息，一旦收到消息就会立刻执行消息。 启动了一个任务之后，可以看到之前启动的worker已经开始执行任务了。 现在是在python环境中调用的add函数，实际上通常在应用程序中调用这个方法。 注意：如果把返回值赋值给一个变量，那么原来的应用程序也会被阻塞，需要等待异步任务返回的结果。因此，实际使用中，不需要把结果赋值。 应用程序中调用方法 新建一个 main.py 文件 代码如下： 在celery命令行可以看见celery执行的日志。打开 backend的redis，也可以看见celery执行的信息。 使用 查看 Redis 数据库内容如图： Celery 的配置比较多，可以在 官方配置文档： 查询每个配置项的含义。 上述的使用是简单的配置，下面介绍一个更健壮的方式来使用celery。首先创建一个python包，celery服务，姑且命名为proj。目录文件如下： ? proj tree . ├── __init__.py ├── celery.py # 创建 celery 实例 ├── config.py # 配置文件 └── tasks.py # 任务函数 首先是 celery.py 这一次创建 app，并没有直接指定 broker 和 backend。而是在配置文件中。 config.py 剩下的就是tasks.py 使用方法也很简单，在 proj 的同一级目录执行 celery： 现在使用任务也很简单，直接在客户端代码调用 proj.tasks 里的函数即可。 Celery的官方文档 。先看代码（tasks.py）： 上面的tasks.py中，首先定义了一个Celery对象，然后用celeryconfig.py对celery对象进行设置，之后再分别定义了三个task，分别是taskA，taskB和add。接下来看一下celeryconfig.py 文件 在 celeryconfig.py 文件中，首先设置了brokel以及result_backend，接下来定义了三个Message Queue,并且指明了Queue对应的Exchange(当使用Redis作为broker时，Exchange的名字必须和Queue的名字一样)以及routing_key的值。 现在在一台主机上面启动一个worker，这个worker只执行for_task_A队列中的消息，这是通过在启动worker是使用-Q Queue_Name参数指定的。 然后到另一台主机上面执行taskA任务。首先 切换当前目录到代码所在的工程下，启动python,执行下面代码启动taskA： 执行完上面的代码之后，task_A消息会被立即发送到for_task_A队列中去。此时已经启动的worker.atsgxxx 会立即执行taskA任务。 重复上面的过程，在另外一台机器上启动一个worker专门执行for_task_B中的任务。修改上一步骤的代码，把 taskA 改成 taskB 并执行。 在上面的 tasks.py 文件中还定义了add任务，但是在celeryconfig.py文件中没有指定这个任务route到那个Queue中去执行，此时执行add任务的时候，add会route到Celery默认的名字叫做celery的队列中去。 因为这个消息没有在celeryconfig.py文件中指定应该route到哪一个Queue中，所以会被发送到默认的名字为celery的Queue中，但是我们还没有启动worker执行celery中的任务。接下来我们在启动一个worker执行celery队列中的任务。 然后再查看add的状态，会发现状态由PENDING变成了SUCCESS。 一种常见的需求是每隔一段时间执行一个任务。 在celery中执行定时任务非常简单，只需要设置celery对象的CELERYBEAT_SCHEDULE属性即可。 配置如下 config.py 注意配置文件需要指定时区。这段代码表示每隔30秒执行 add 函数。一旦使用了 scheduler, 启动 celery需要加上-B 参数。 设置多个定时任务 定义3个定时任务,即每隔20s执行taskA任务，参数为(5,6),每隔200s执行taskB任务,参数为(10,20,30),每隔10s执行add任务，参数为(1,2).通过下列命令启动一个定时任务: celery -A tasks beat。使用 beat 参数即可启动定时任务。 计划任务当然也可以用crontab实现，celery也有crontab模式。修改 config.py scheduler的切分度很细，可以精确到秒。crontab模式就不用说了。 当然celery还有更高级的用法，比如 多个机器 使用，启用多个 worker并发处理 等。 发送任务到队列中 apply_async(args[, kwargs[, …]])、delay(*args, **kwargs) ： send_task ： 输入 celery -h 可以看到 celery 的命令和帮助 更详细的帮助可以看官方文档： 官网示例： 第一步 编写简单的纯python函数 第二步 如果这个函数不是简单的输出两个字符串相加，而是需要查询数据库或者进行复杂的处理。这种处理需要耗费大量的时间，还是这种方式执行会是多么糟糕的事情。为了演示这种现象，可以使用sleep函数来高耗时任务。 第三步 这时候我们可能会思考怎么使用多进程或者多线程去实现这种任务。对于多进程与多线程的不足这里不做讨论。现在我们可以想想celery到底能不能解决这种问题。 现在来解释一下新加入的几行代码，首先说明一下加入的新代码完全不需要改变原来的代码。导入celery模块就不用解释了，声明一个celery实例app的参数需要解释一下。 第一个参数是这个python文件的名字，注意到已经把.py去掉了。 第二个参数是用到的rabbitmq队列。可以看到其使用的方式非常简单，因为它是默认的消息队列端口号都不需要指明。 第四步 现在我们已经使用了celery框架了，我们需要让它找几个工人帮我们干活。好现在就让他们干活。 这条命令有些长，我来解释一下吧。 -A 代表的是Application的首字母，我们的应用就是在 sample 里面 定义的。 worker 就是我们的工人了，他们会努力完成我们的工作的。 -loglevel=info 指明了我们的工作后台执行情况，虽然工人们已经向你保证过一定努力完成任务。但是谨慎的你还是希望看看工作进展情况。 第五步 现在我们的任务已经被加载到了内存中，我们不能再像之前那样执行python sample.py来运行程序了。我们可以通过终端进入python然后通过下面的方式加载任务。输入python语句。 我们的函数会立即返回，不需要等待。就那么简单celery解决了我们的问题。可以发现我们的say函数不是直接调用了，它被celery 的 task 装饰器 修饰过了。所以多了一些属性。目前我们只需要知道使用delay就行了。 确保你之前的RabbitMQ已经启动。还是官网的那个例子，在任意目录新建一个tasks.py的文件，内容如下： 使用作为消息队列 在同级目录执行: 该命令的意思是启动一个worker ( tasks文件中的app实例，默认实例名为app，-A 参数后也可直接加文件名，不需要 .app)，把tasks中的任务（add(x,y)）把任务放到队列中。保持窗口打开，一个窗口进入交互模式，python或者ipython: ，你已经可以使用celery执行任务了，上面的python交互模式下简单的调用了add任务，并传递 4，4 参数。 但此时有一个问题，你突然想知道这个任务的执行结果和状态，到底完了没有。因此就需要设置backend了 修改之前的tasks.py中的代码为： 除了添加backend之外，上面还添加了一个who的方法用来多操作。修改完成之后，还按之前的方式启动。 同样进入python的交互模型: 做完上面的测试之后，产生了一个疑惑，Celery叫做分布式任务管理，那它的分布式体现？它的任务都是怎么执行的？个机器上执行的？在当前服务器上的celery服务不关闭的情况下，按照同样的方式在另外一台服务器上安装Celery，并启动: 发现前一个服务器的Celery服务中输出你刚启动的服务器的hostname，前提是那台服务器连上了你的rabbitmq。然后再进入python交互模式: 看你输入的内容已经观察两台服务器上你启动celery服务的输出。 在实际的项目中我们需要明确前后台的分界线，因此我们的celery编写的时候就应该是分成前后台两个部分编写。在celery简单入门中的总结部分我们也提出了另外一个问题，就是需要分离celery的配置文件。 第一步 编写后台任务tasks.py脚本文件。在这个文件中我们不需要再声明celery的实例，我们只需要导入其task装饰器来注册我们的任务即可。后台处理业务逻辑完全独立于前台，这里只是简单的hello world程序需要多少个参数只需要告诉前台就可以了，在实际项目中可能你需要的是后台执行发送一封邮件的任务或者进行复杂的数据库查询任务等。 第二步 有了那么完美的后台，我们的前台编写肯定也轻松不少。到底简单到什么地步呢，来看看前台的代码吧！为了形象的表明其职能，我们将其命名为client.py脚本文件。 可以看到只需要简单的几步：1. 声明一个celery实例。2. 加载配置文件。3. 发送任务。 第三步 继续完成celery的配置。官方的介绍使用celeryconfig.py作为配置文件名，这样可以防止与你现在的应用的配置同名。 可以看到我们指定了CELERY_RESULT_BACKEND为amqp默认的队列！这样我们就可以查看处理后的运行状态了，后面将会介绍处理结果的查看。 第四步 启动celery后台服务，这里是测试与学习celery的教程。在实际生产环境中，如果是通过这种方式启动的后台进程是不行的。所谓后台进程通常是需要作为守护进程运行在后台的，在python的世界里总是有一些工具能够满足你的需要。这里可以使用supervisor作为进程管理工具。在后面的文章中将会介绍如何使用supervisor工具。 注意现在运行worker的方式也与前面介绍的不一样了，下面简单介绍各个参数。 第五步 前台的运行就比较简单了，与平时运行的python脚本一样。python client.py。 现在前台的任务是运行了，可是任务是被写死了。我们的任务大多数时候是动态的，为演示动态工作的情况我们可以使用终端发送任务。 在python终端导入celery模块声明实例然后加载配置文件，完成了这些步骤后就可以动态的发送任务并且查看任务状态了。注意在配置文件celeryconfig.py中我们已经开启了处理的结果回应模式了CELERY_IGNORE_RESULT = False并且在回应方式配置中我们设置了CELERY_RESULT_BACKEND = 'amqp'这样我们就可以查看到处理的状态了。 可以看到任务发送给celery后马上查看任务状态会处于PENDING状态。稍等片刻就可以查看到SUCCESS状态了。这种效果真棒不是吗？在图像处理中或者其他的一些搞耗时的任务中，我们只需要把任务发送给后台就不用去管它了。当我们需要结果的时候只需要查看一些是否成功完成了，如果返回成功我们就可以去后台数据库去找处理后生成的数据了。 第一步 安装好mongodb了！就可以使用它了，首先让我们修改celeryconfig.py文件，使celery知道我们有一个新成员要加入我们的项目，它就是mongodb配置的方式如下。 把#CELERY_RESULT_BACKEND = 'amp'注释掉了，但是没有删除目的是对比前后的改变。为了使用mongodb我们有简单了配置一下主机端口以及数据库名字等。显然你可以按照你喜欢的名字来配置它。 第二步 启动 mongodb 数据库：mongod。修改客户端client.py让他能够动态的传人我们的数据，非常简单代码如下。 任务tasks.py不需要修改！ 第三步 测试代码，先启动celery任务。 再来启动我们的客户端，注意这次启动的时候需要给两个参数啦！ 等上5秒钟，我们的后台处理完成后我们就可以去查看数据库了。 第四步 查看mongodb，需要启动一个mongodb客户端，启动非常简单直接输入 mongo 。然后是输入一些简单的mongo查询语句。 最后查到的数据结果可能是你不想看到的，因为mongo已经进行了处理。想了解更多可以查看官方的文档。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
