Celery 2.0 的更改历史记录 — Python 文档
Celery 2.0 的更改历史记录
2.0.3
- 发布日期
- 2010-08-27 12:00 下午 中科院
- 发布者
- 问庄严
修复
Worker:正确处理关闭消费者时发生的连接错误。
Worker:如果连接断开,事件现在被缓冲,然后在连接重新建立时发送。
不再依赖于 :pypi:`mailer` 包。
这个包与 django-mailer 有命名空间冲突,所以它的功能被替换了。
Redis 结果后端:文档拼写错误:Redis 没有数据库名称,但有数据库编号。 默认数据库现在是 0。
inspect
:registered_tasks 由于输入错误而请求无效命令。见问题#170。
:setting:`CELERY_ROUTES`:合并两者时,路由中定义的值现在应该优先于 :setting:`CELERY_QUEUES` 中定义的值。
使用以下设置:
CELERY_QUEUES = {'cpubound': {'exchange': 'cpubound', 'routing_key': 'cpubound'}} CELERY_ROUTES = {'tasks.add': {'queue': 'cpubound', 'routing_key': 'tasks.add', 'serializer': 'json'}}
tasks.add 的最终路由选项将变为:
{'exchange': 'cpubound', 'routing_key': 'tasks.add', 'serializer': 'json'}
以前不是这样::setting:`CELERY_QUEUES` 中的值将优先。
如果 :setting:`CELERY_TASK_ERROR_WHITELIST` 的值不是可迭代的,则 Worker 崩溃
apply()
:确保始终设置 kwargs['task_id']。AsyncResult.traceback:现在返回
None
,而不是在缺少回溯时提高KeyError
。inspect
:如果未指定目的地,回复将无法正常工作。现在可以存储自定义状态的结果/元数据。
Worker:如果发送任务错误电子邮件失败,现在会发出警告。
celeryev
:如果调整终端窗口大小,Curses 监视器不再崩溃。请参阅问题 #160。
Worker:在 macOS 上,无法在线程化进程中运行 os.exec*。
这会破坏 SIGHUP 重启处理程序,现在在 macOS 上被禁用,而是发出警告。
见问题#152。
celery.execute.trace
:正确处理 raise(str),这在 Python 2.4 中仍然是允许的。见问题#175。
由于 macOS 中使用的代理自动检测,在 macOS 上的定期任务中使用 urllib2 崩溃。
现在已通过使用变通方法解决此问题。 见问题#143。
Debian init-scripts:命令不应在子 shell 中运行
见问题#163。
Debian init-scripts: 使用
celeryd
程序的绝对路径来允许 stat见问题#162。
文档
入门/代理安装:修正了错字
set_permissions “” -> set_permissions “.*”。
任务用户指南:添加了关于数据库事务的部分。
见问题#169。
路由用户指南:修正拼写错误 “feed”:-> {“queue”:“feeds”}。
见问题#169。
记录了 :setting:`CELERYD_CONCURRENCY` 和 :setting:`CELERYD_PREFETCH_MULTIPLIER` 设置的默认值。
任务用户指南:修复了子任务示例中的拼写错误
celery.signals:记录的 worker_process_init。
守护程序手册:需要在 /etc/default/celeryd 中导出 DJANGO_SETTINGS_MODULE。
添加了更多关于堆栈溢出的常见问题解答
守护程序手册:修正错字 CELERYD_LOGFILE/CELERYD_PIDFILE
到 CELERYD_LOG_FILE / CELERYD_PID_FILE
还为初始化脚本添加了故障排除部分。
2.0.2
- 发布日期
- 2010-07-22 11:31 上午 中科院
- 发布者
- 问庄严
路由:使用 dict 路由语法时,对任务的交换可能会消失,从而使任务无法路由。
见问题#158。
测试套件现在通过 Python 2.4
不再需要输入 PYTHONPATH=. 才能在当前目录中使用
celeryconfig
。这是由默认加载器完成的,确保在加载配置模块时当前目录位于 sys.path 中。 sys.path 加载后重置为原始状态。
在用户不知情的情况下将当前工作目录添加到 sys.path 可能是一个安全问题,因为这意味着有人可以在用户目录中放置一个执行任意命令的 Python 模块。 这是不这样做的最初原因,但如果仅在加载配置模块 时才执行 ,这意味着该行为将仅适用于配置模块中导入的模块,我认为这是一个很好的折衷(当然比仅仅显式设置 PYTHONPATH=. 更好)
添加了实验性 Cassandra 后端。
工人:SIGHUP 处理程序意外传播到工作池进程。
结合 :sha:`7a7c44e39344789f11b5346e9cc8340f5fe4846c` 这将使每个子进程在终端窗口关闭时启动一个新的工作实例:/
Worker:如果从终端运行,请不要安装 SIGHUP 处理程序。
这解决了关闭终端时在后台启动工作程序的问题。
工人:现在在关闭时加入线程。
见问题#152。
测试拆卸:不要使用 atexit 而是使用鼻子的 teardown() 功能。
见问题#154。
Debian worker init-script: Stop 现在可以正常工作了。
任务记录器:添加了 warn 方法(warning 的同义词)
现在可以定义错误的白名单以发送错误电子邮件。
示例:
CELERY_TASK_ERROR_WHITELIST = ('myapp.MalformedInputError',)
请参阅问题 #153。
Worker:现在在解析 ETA 字段时处理 time.mktime 中的溢出异常。
LoggerWrapper:尝试检测记录回 stderr/stdout 的记录器,从而形成无限循环。
添加了
celery.task.control.inspect
:检查正在运行的工人。例子:
# Inspect a single worker >>> i = inspect('myworker.example.com') # Inspect several workers >>> i = inspect(['myworker.example.com', 'myworker2.example.com']) # Inspect all workers consuming on this vhost. >>> i = inspect() ### Methods # Get currently executing tasks >>> i.active() # Get currently reserved tasks >>> i.reserved() # Get the current ETA schedule >>> i.scheduled() # Worker statistics and info >>> i.stats() # List of currently revoked tasks >>> i.revoked() # List of registered tasks >>> i.registered_tasks()
远程控制命令 dump_active/dump_reserved/dump_schedule 现在回复详细的任务请求。
包含请求的任务的原始参数和字段。
另外增加了远程控制命令set_loglevel,这只改变了主进程的日志级别。
工作人员控制命令执行现在捕获错误并在回复中返回它们的字符串表示。
添加了功能测试套件
celery.tests.functional.case
包含用于启动和停止嵌入式工作进程的实用程序,用于功能测试。
2.0.1
- 发布日期
- 2010-07-09 03:02 下午 中科院
- 发布者
- 问庄严
multiprocessing.pool:现在处理编码错误,因此酸洗错误不会使工作进程崩溃。
远程控制命令回复不适用于 RabbitMQ 1.8.0 更严格的等效性检查。
如果您已经遇到此问题,则可能必须删除声明:
$ camqadm exchange.delete celerycrq
或:
$ python manage.py camqadm exchange.delete celerycrq
ETA 调度程序中潜藏了一个错误,使其每秒只能执行一项任务(!)
调度程序在迭代之间休眠,因此它不会消耗太多 CPU。 它保留一个按时间排序的计划项目列表,在每次迭代时,它会在最接近截止日期的项目的剩余时间内休眠。 如果没有 ETA 任务,它将休眠最短时间,默认为一秒。
一个错误潜入这里,让它为每一个预定的任务休眠一秒钟。 这已被修复,所以现在它应该移动诸如热刀穿过黄油之类的任务。
此外还添加了一个新设置来控制最小睡眠间隔; :设置:`CELERYD_ETA_SCHEDULER_PRECISION`。 一个很好的值是介于 0 和 1 之间的浮点数,具体取决于所需的精度。 值为 0.8 表示当满足任务的 ETA 时,任务移动到就绪队列最多需要 0.8 秒。
池:主管没有释放信号量。
如果所有工人过早终止,这将导致僵局。
添加了 Python 版本的 trove 分类器:2.4、2.5、2.6 和 2.7
测试现在通过 Python 2.7。
Task.__reduce__:现在可以腌制使用任务装饰器创建的任务。
setup.py
: :pypi:`nose` 添加到 tests_require。Pickle 现在应该可以与 SQLAlchemy 0.5.x 一起使用
Jan Henrik Helmers 的新主页设计:http://celeryproject.org
Armin Ronacher 的新 Sphinx 主题:http://docs.celeryproject.org/
修复了文档 HTML 呈现中显示的“pending_xref”错误。 显然这是由 Sphinx 1.0b2 中的新变化引起的。
:setting:`CELERY_ROUTES` 中的路由器类现在被延迟导入。
在加载 Celery 环境的模块中导入路由器类会导致循环依赖。 这是通过在设置环境后在需要时导入它来解决的。
:setting:`CELERY_ROUTES` 如果设置为单个字典会被破坏。
文档中的这个例子现在应该可以再次工作了:
CELERY_ROUTES = {'feed.tasks.import_feed': 'feeds'}
CREATE_MISSING_QUEUES 没有被 apply_async 认可。
新的远程控制命令:stats
转储有关工作程序的信息,例如池进程 ID 和按类型执行的任务总数。
回复示例:
[{'worker.local': 'total': {'tasks.sleeptask': 6}, 'pool': {'timeouts': [None, None], 'processes': [60376, 60377], 'max-concurrency': 2, 'max-tasks-per-child': None, 'put-guarded-by-semaphore': True}}]
新的远程控制命令:dump_active
给出工作人员当前正在执行的任务列表。 默认情况下,参数通过 repr 传递,以防存在不可 JSON 编码的参数。 如果您知道参数是 JSON 安全的,则可以传递参数 safe=True。
回复示例:
>>> broadcast('dump_active', arguments={'safe': False}, reply=True) [{'worker.local': [ {'args': '(1,)', 'time_start': 1278580542.6300001, 'name': 'tasks.sleeptask', 'delivery_info': { 'consumer_tag': '30', 'routing_key': 'celery', 'exchange': 'celery'}, 'hostname': 'casper.local', 'acknowledged': True, 'kwargs': '{}', 'id': '802e93e9-e470-47ed-b913-06de8510aca2', } ]}]
添加了对持久撤销的实验支持。
使用 -S|–statedb 参数给 worker 启用它:
$ celeryd --statedb=/var/run/celeryd
这将使用文件:/var/run/celeryd.db,因为 shelve 模块会自动添加 .db 后缀。
2.0.0
- 发布日期
- 2010-07-02 02:30 下午 中科院
- 发布者
- 问庄严
前言
Celery 2.0 包含向后不兼容的更改,最重要的是删除了 Django 依赖项,因此 Celery 不再支持开箱即用的 Django,而是作为一个名为 :pypi:`django-celery`[ X237X]。
我们非常抱歉破坏了向后兼容性,但还有许多令人兴奋的新功能可以弥补您失去升级的时间,因此请务必阅读 新闻 部分。
相当多的潜在用户对 Django 的依赖感到不安,所以也许这也是一个被 Python 社区更广泛采用的机会。
非常感谢所有贡献者、测试人员和用户!
为 Django 用户升级
Django 集成已移至单独的包::pypi:`django-celery`。
要升级,您需要安装 :pypi:`django-celery` 模块并更改:
INSTALLED_APPS = 'celery'
到:
INSTALLED_APPS = 'djcelery'
如果您使用 mod_wsgi,您需要将以下行添加到您的 .wsgi 文件中:
import os os.environ['CELERY_LOADER'] = 'django'
以下模块已移至 :pypi:`django-celery`:
模块名称
用。。。来代替
celery.models
djcelery.models
celery.managers
djcelery.managers
celery.views
djcelery.views
celery.urls
djcelery.urls
celery.management
djcelery.management
celery.loaders.djangoapp
djcelery.loaders
celery.backends.database
djcelery.backends.database
celery.backends.cache
djcelery.backends.cache
导入 djcelery
将自动设置 Celery 以使用 Django 加载器。 装载机。 它通过将 CELERY_LOADER
环境变量设置为 “django”(如果加载程序已经设置,则不会更改它)来实现这一点。
使用 Django 加载器时,“数据库”和“缓存”结果后端别名将指向 djcelery
后端而不是内置后端,并且将从 Django 设置中读取配置。
为他人升级
数据库结果后端
数据库结果后端现在使用 SQLAlchemy 而不是 Django ORM,请参阅 Supported Databases 以获取支持的数据库表。
DATABASE_* 设置已替换为单个设置::setting:`CELERY_RESULT_DBURI`。 这里的值应该是一个 SQLAlchemy Connection String,一些例子包括:
# sqlite (filename)
CELERY_RESULT_DBURI = 'sqlite:///celerydb.sqlite'
# mysql
CELERY_RESULT_DBURI = 'mysql://scott:tiger@localhost/foo'
# postgresql
CELERY_RESULT_DBURI = 'postgresql://scott:tiger@localhost/mydatabase'
# oracle
CELERY_RESULT_DBURI = 'oracle://scott:tiger@127.0.0.1:1521/sidname'
有关连接字符串的更多信息,请参阅 SQLAlchemy 连接字符串 。
要指定其他 SQLAlchemy 数据库引擎选项,您可以使用 :setting:`CELERY_RESULT_ENGINE_OPTIONS` 设置:
# echo enables verbose logging from SQLAlchemy. CELERY_RESULT_ENGINE_OPTIONS = {'echo': True}
缓存结果后端
缓存结果后端不再使用 Django 缓存框架,但它支持大部分相同的配置语法:
CELERY_CACHE_BACKEND = 'memcached://A.example.com:11211;B.example.com'
要使用缓存后端,您必须安装 :pypi:`pylibmc` 或 :pypi:`python-memcached` 库,其中前者被认为是最佳选择.
支持的后端类型有 memcached:// 和 memory://,我们还没有觉得需要支持 Django 提供的任何其他后端。
向后不兼容的更改
默认 (python) 加载程序现在会在缺少 celeryconfig.py 时打印警告,而不是提升
ImportError
。如果未设置配置,worker 会引发
@ImproperlyConfigured
。 这使得可以使用 –help 等,而无需进行工作配置。这也使得无需配置即可使用 Celery 的客户端成为可能:
>>> from carrot.connection import BrokerConnection >>> conn = BrokerConnection('localhost', 'guest', 'guest', '/') >>> from celery.execute import send_task >>> r = send_task('celery.ping', args=(), kwargs={}, connection=conn) >>> from celery.backends.amqp import AMQPBackend >>> r.backend = AMQPBackend(connection=conn) >>> r.get() 'pong'
以下已弃用的设置已被删除(按照 Celery 弃用时间线 的安排):
设置名称
用。。。来代替
CELERY_AMQP_CONSUMER_QUEUES
CELERY_QUEUES
CELERY_AMQP_EXCHANGE
CELERY_DEFAULT_EXCHANGE
CELERY_AMQP_EXCHANGE_TYPE
CELERY_DEFAULT_EXCHANGE_TYPE
CELERY_AMQP_CONSUMER_ROUTING_KEY
CELERY_QUEUES
CELERY_AMQP_PUBLISHER_ROUTING_KEY
CELERY_DEFAULT_ROUTING_KEY
celery.task.rest 模块已被移除,使用 celery.task.http 代替(如 Celery Deprecation Time-line 计划的那样)。
不再允许在加载器名称中跳过类名。 (按照 Celery 弃用时间表 的安排):
假设不再支持隐式 Loader 类名,例如,如果您使用:
CELERY_LOADER = 'myapp.loaders'
您需要包含加载器类名,如下所示:
CELERY_LOADER = 'myapp.loaders.Loader'
:setting:`CELERY_TASK_RESULT_EXPIRES` 现在默认为 1 天。
以前的默认设置是在 5 天后过期。
AMQP 后端:不要为 auto_delete 使用不同的值。
这个错误在 RabbitMQ 1.8.0 中变得可见,它不再允许 auto_delete 和持久设置的声明发生冲突。
如果您已经在此后端使用 Celery,则您必须删除之前的声明:
$ camqadm exchange.delete celeryresults
现在在 Python 版本 <= 2.5 上使用 pickle 而不是 cPickle
cPickle 在 Python <= 2.5 中被破坏。
它不安全且不正确地使用相对而不是绝对导入,例如:
exceptions.KeyError
变成:
celery.exceptions.KeyError
您最好的选择是升级到 Python 2.6,因为虽然纯 pickle 版本的性能更差,但它是旧 Python 版本的唯一安全选择。
新闻
celeryev:诅咒芹菜监视器和事件查看器。
这是一个简单的监视器,允许您实时查看正在执行的任务并调查就绪任务的回溯和结果。 它还使您能够设置新的速率限制和撤销任务。
截图:
如果您使用 -d 开关运行 celeryev,它将充当事件转储器,只需将接收到的事件转储到标准输出:
$ celeryev -d -> celeryev: starting capture... casper.local [2010-06-04 10:42:07.020000] heartbeat casper.local [2010-06-04 10:42:14.750000] task received: tasks.add(61a68756-27f4-4879-b816-3cf815672b0e) args=[2, 2] kwargs={} eta=2010-06-04T10:42:16.669290, retries=0 casper.local [2010-06-04 10:42:17.230000] task started tasks.add(61a68756-27f4-4879-b816-3cf815672b0e) args=[2, 2] kwargs={} casper.local [2010-06-04 10:42:17.960000] task succeeded: tasks.add(61a68756-27f4-4879-b816-3cf815672b0e) args=[2, 2] kwargs={} result=4, runtime=0.782663106918 The fields here are, in order: *sender hostname*, *timestamp*, *event type* and *additional event fields*.
AMQP 结果后端:现在支持 [X34X].ready(), .successful(), .result, .status,甚至响应任务状态的变化
新用户指南:
工人:标准输出/错误现在被重定向到日志文件。
:pypi:`billiard` 已移回 Celery 存储库。
模块名称
芹菜当量
台球池
celery.concurrency.processes.pool
台球.序列化
celery.序列化
billiard.utils.functional
celery.utils.functional
:pypi:`billiard` 分布可能会保留,具体取决于兴趣。
现在取决于 :pypi:`carrot` >= 0.10.5
现在取决于 :pypi:`pyparsing`
Worker:添加了 -purge 作为 -discard 的别名。
工人:Control-c (SIGINT) 一次执行热关机,点击 Control-c 两次强制终止。
添加了对在周期性任务中使用复杂 Crontab 表达式的支持。 例如,您现在可以使用:
>>> crontab(minute='*/15')
甚至:
>>> crontab(minute='*/30', hour='8-17,1-2', day_of_week='thu-fri')
请参阅 定期任务 。
Worker:现在在将新任务应用到池之前等待可用的池进程。
这意味着它不必在关闭时等待数十个任务完成,因为它已经应用了预取任务,而没有任何可用的池进程可以立即接受它们。
见问题#122。
使用
subtask
执行任务回调的新内置方法。有关更多信息,请参阅 Canvas:设计工作流 。
任务集现在可以包含多种类型的任务。
TaskSet
已重构为使用新语法,请参阅 Canvas: Designing Work-flows 了解更多信息。仍然支持以前的语法,但将在 1.4 版中弃用。
TaskSet failed() 结果不正确。
见问题#132。
现在为每个任务类创建不同的记录器。
见问题#129。
现在会自动创建缺少的队列定义。
您可以使用 :setting:`CELERY_CREATE_MISSING_QUEUES` 设置禁用此功能。
使用以下选项创建丢失的队列:
CELERY_QUEUES[name] = {'exchange': name, 'exchange_type': 'direct', 'routing_key': 'name}
添加此功能是为了使用 -Q 选项轻松设置工作线程的路由:
$ celeryd -Q video, image
有关详细信息,请参阅用户指南的新路由部分:Routing Tasks。
新任务选项:Task.queue
如果设置,消息选项将从 :setting:`CELERY_QUEUES` 中的相应条目中获取。 exchange、exchange_type 和 routing_key 将被忽略
添加了对任务软硬时间限制的支持。
添加了新设置:
-
硬时间限制。 当超过这个值时,处理任务的工作人员将被杀死并替换为新的工作人员。
:设置:`CELERYD_TASK_SOFT_TIME_LIMIT`
软时间限制。 超过此值时将引发
@SoftTimeLimitExceeded
异常。 例如,任务可以捕捉到这一点,以便在硬时间限制到来之前进行清理。
celeryd
的新命令行参数添加:–time-limit 和 –soft-time-limit。还剩下什么?
这不适用于不支持信号(特别是 SIGUSR1 信号)的平台。 因此,必须实现在不合格平台上一起禁用该功能的替代方案。
同样当超过硬时间限制时,任务结果应该是 TimeLimitExceeded 异常。
-
测试套件现在在没有运行代理的情况下通过,使用胡萝卜内存后端。
日志输出现在有颜色。
日志级别
颜色
调试
蓝色
警告
黄色
危急
洋红色
错误
红色
这仅在日志输出为 tty 时启用。 您可以使用 :setting:`CELERYD_LOG_COLOR` 设置显式启用/禁用此功能。
添加了对任务路由器类的支持(如 django 多数据库路由器)
这是发送任务时要遍历的单个路由器或路由器列表。 此列表中的字典转换为
celery.routes.MapRoute
实例。例子:
>>> CELERY_ROUTES = {'celery.ping': 'default', 'mytasks.add': 'cpu-bound', 'video.encode': { 'queue': 'video', 'exchange': 'media' 'routing_key': 'media.video.encode'}}
>>> CELERY_ROUTES = ('myapp.tasks.Router', {'celery.ping': 'default'})
myapp.tasks.Router 可以是:
class Router(object): def route_for_task(self, task, args=None, kwargs=None): if task == 'celery.ping': return 'default'
route_for_task 可能会返回一个字符串或一个字典。 字符串则表示它是 :setting:`CELERY_QUEUES` 中的队列名称,字典表示它是自定义路由。
发送任务时,按顺序查询路由器。 第一个不返回 None 的路由器是要使用的路由。 然后将消息选项与找到的路由设置合并,其中路由器设置具有优先权。
如果
apply_async()
具有以下参数的示例:>>> Task.apply_async(immediate=False, exchange='video', ... routing_key='video.compress')
一个路由器返回:
{'immediate': True, 'exchange': 'urgent'}
最终的消息选项将是:
>>> task.apply_async( ... immediate=True, ... exchange='urgent', ... routing_key='video.compress', ... )
(以及
Task
类中定义的任何默认消息选项)任务返回后调用的新任务处理程序:
after_return()
。ExceptionInfo
现在传递给on_retry()
/on_failure()
作为einfo
关键字参数。
工人:添加了 :setting:`CELERYD_MAX_TASKS_PER_CHILD` /
celery worker --maxtasksperchild
。定义池工作者在进程终止并由新任务替换之前可以处理的最大任务数。
现在标记为状态 :state:`REVOKED` 和 result.get() 的已撤销任务现在将引发
@TaskRevokedError
。celery.task.control.ping()
现在按预期工作。apply(throw=True) / :setting:`CELERY_EAGER_PROPAGATES_EXCEPTIONS`:使急切执行重新引发任务错误。
新信号::signal:`~celery.signals.worker_process_init`:在初始化时在池工作进程内发送。
Worker:
celery worker -Q
选项:能够指定要使用的队列列表,禁用其他配置的队列。例如,如果 :setting:`CELERY_QUEUES` 定义了四个队列:image、video、data 和 default ],以下命令将使工作程序仅从 image 和 video 队列中消费:
$ celeryd -Q image,video
Worker:revoke 控制命令的新返回值:
现在返回:
{'ok': 'task $id revoked'}
而不是
True
。Worker:现在可以使用远程控制启用/禁用事件
用法示例:
>>> from celery.task.control import broadcast >>> broadcast('enable_events') >>> broadcast('disable_events')
删除了顶级测试目录。 现在在 celery.tests.config 中测试配置
这意味着运行单元测试不需要任何特殊设置。 celery/tests/__init__ 现在配置了
CELERY_CONFIG_MODULE
和CELERY_LOADER
环境变量,所以当 nosetests ] 导入,单元测试环境都设置好了。在运行测试之前,您需要安装测试要求:
$ pip install -r requirements/test.txt
运行所有测试:
$ nosetests
指定要运行的测试:
$ nosetests celery.tests.test_task
生成 HTML 覆盖率:
$ nosetests --with-coverage3
然后覆盖输出位于 celery/tests/cover/index.html。
Worker:新选项 –version:转储版本信息并退出。
celeryd-multi
:shell 脚本启动多个 worker 的工具。一些例子:
具有 10 个工人的高级示例:
三名工人处理图像和视频队列
两个工作人员使用日志级别 DEBUG 处理数据队列
其余的处理默认的'队列。
$ celeryd-multi start 10 -l INFO -Q:1-3 images,video -Q:4,5:data -Q default -L:4,5 DEBUG
获取启动 10 个工人的命令,每个工人有 3 个进程
$ celeryd-multi start 3 -c 3 celeryd -n celeryd1.myhost -c 3 celeryd -n celeryd2.myhost -c 3 celeryd -n celeryd3.myhost -c 3
启动 3 个命名工人
$ celeryd-multi start image video data -c 3 celeryd -n image.myhost -c 3 celeryd -n video.myhost -c 3 celeryd -n data.myhost -c 3
指定自定义主机名
$ celeryd-multi start 2 -n worker.example.com -c 3 celeryd -n celeryd1.worker.example.com -c 3 celeryd -n celeryd2.worker.example.com -c 3
每个
celeryd
都添加了附加选项,但您也可以修改范围或单个工人的选项3人:2人3道工序,1人10道工序。
$ celeryd-multi start 3 -c 3 -c:1 10 celeryd -n celeryd1.myhost -c 10 celeryd -n celeryd2.myhost -c 3 celeryd -n celeryd3.myhost -c 3
还可以为命名工人指定选项
$ celeryd-multi start image video data -c 3 -c:image 10 celeryd -n image.myhost -c 10 celeryd -n video.myhost -c 3 celeryd -n data.myhost -c 3
还允许选项中的工作人员范围和列表:(
-c:1-3
也可以写为-c:1,2,3
)$ celeryd-multi start 5 -c 3 -c:1-3 10 celeryd-multi -n celeryd1.myhost -c 10 celeryd-multi -n celeryd2.myhost -c 10 celeryd-multi -n celeryd3.myhost -c 10 celeryd-multi -n celeryd4.myhost -c 3 celeryd-multi -n celeryd5.myhost -c 3
列表也适用于命名工人:
$ celeryd-multi start foo bar baz xuzzy -c 3 -c:foo,bar,baz 10 celeryd-multi -n foo.myhost -c 10 celeryd-multi -n bar.myhost -c 10 celeryd-multi -n baz.myhost -c 10 celeryd-multi -n xuzzy.myhost -c 3
工作人员现在调用结果后端 process_cleanup 方法 after 任务执行而不是之前。
AMQP 结果后端现在支持 Pika。