Конфигурация и настройки по умолчанию¶
В этом документе описаны доступные варианты конфигурации.
Если вы используете загрузчик по умолчанию, вы должны создать модуль celeryconfig.py
и убедиться, что он доступен в пути Python.
Пример конфигурационного файла¶
Это пример конфигурационного файла для начала работы. Он должен содержать все необходимое для запуска базовой установки Celery.
## Broker settings.
broker_url = 'amqp://guest:guest@localhost:5672//'
# List of modules to import when the Celery worker starts.
imports = ('myapp.tasks',)
## Using the database to store task state and results.
result_backend = 'db+sqlite:///results.db'
task_annotations = {'tasks.add': {'rate_limit': '10/s'}}
Новые настройки строчных букв¶
В версии 4.0 введены новые настройки нижнего регистра и организация настроек.
Основным отличием от предыдущих версий, помимо имен в нижнем регистре, является переименование некоторых префиксов, например, celery_beat_
в beat_
, celeryd_
в worker_
, а большинство настроек верхнего уровня celery_
были перенесены в новый префикс task_
.
Предупреждение
Celery будет по-прежнему способен читать старые конфигурационные файлы до версии Celery 6.0. После этого поддержка старых конфигурационных файлов будет удалена. Мы предоставляем команду celery upgrade
, которая должна справиться со многими случаями (включая Django).
Пожалуйста, перейдите на новую схему конфигурации как можно скорее.
Имя установки |
Заменить на |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Вместо этого используйте |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Директивы конфигурации¶
Общие настройки¶
accept_content
¶
По умолчанию: {'json'}
(набор, список или кортеж).
Белый список типов содержимого/сериализаторов для разрешения.
Если получено сообщение, которого нет в этом списке, то оно будет отброшено с ошибкой.
По умолчанию включен только json, но можно добавить любой тип содержимого, включая pickle и yaml; в этом случае убедитесь, что ненадежные стороны не имеют доступа к вашему брокеру. Подробнее смотрите Безопасность.
Пример:
# using serializer name
accept_content = ['json']
# or the actual content-type (MIME)
accept_content = ['application/json']
result_accept_content
¶
По умолчанию: None
(может быть набором, списком или кортежем).
Добавлено в версии 4.3.
Белый список типов содержимого/сериализаторов, разрешенных для бэкенда результатов.
Если получено сообщение, которого нет в этом списке, то оно будет отброшено с ошибкой.
По умолчанию это тот же сериализатор, что и accept_content
. Однако можно указать другой сериализатор для принимаемого содержимого бэкенда результата. Обычно это необходимо, если используется обмен сообщениями с подписями, а результат хранится без знака в бэкенде результата. Подробнее см. в Безопасность.
Пример:
# using serializer name
result_accept_content = ['json']
# or the actual content-type (MIME)
result_accept_content = ['application/json']
Настройки времени и даты¶
enable_utc
¶
Добавлено в версии 2.5.
По умолчанию: Включено по умолчанию с версии 3.0.
Если включено, даты и время в сообщениях будут преобразованы для использования часового пояса UTC.
Обратите внимание, что рабочие под управлением Celery версии ниже 2.5 будут принимать местный часовой пояс для всех сообщений, поэтому включайте эту функцию только в том случае, если все рабочие были обновлены.
timezone
¶
Добавлено в версии 2.5.
По умолчанию: "UTC"
.
Настройте Celery на использование пользовательского часового пояса. Значение часового пояса может быть любым часовым поясом, поддерживаемым библиотекой pytz.
Если значение не установлено, используется часовой пояс UTC. Для обратной совместимости существует также параметр enable_utc
, когда он имеет значение false, вместо него используется локальный часовой пояс системы.
Параметры задачи¶
task_annotations
¶
Добавлено в версии 2.5.
По умолчанию: None
.
Этот параметр можно использовать для перезаписи любого атрибута задачи из конфигурации. Настройка может быть диктой или списком объектов аннотации, которые фильтруют задачи и возвращают карту атрибутов для изменения.
Это изменит атрибут rate_limit
для задачи tasks.add
:
task_annotations = {'tasks.add': {'rate_limit': '10/s'}}
или изменить одинаково для всех задач:
task_annotations = {'*': {'rate_limit': '10/s'}}
Вы можете изменить и методы, например, обработчик on_failure
:
def my_on_failure(self, exc, task_id, args, kwargs, einfo):
print('Oh no! Task failed: {0!r}'.format(exc))
task_annotations = {'*': {'on_failure': my_on_failure}}
Если вам нужна большая гибкость, вы можете использовать объекты вместо диктанта для выбора задач для аннотирования:
class MyAnnotate:
def annotate(self, task):
if task.name.startswith('tasks.'):
return {'rate_limit': '10/s'}
task_annotations = (MyAnnotate(), {other,})
task_compression
¶
По умолчанию: None
Сжатие по умолчанию, используемое для сообщений задач. Может быть gzip
, bzip2
(если доступно), или любые пользовательские схемы сжатия, зарегистрированные в реестре сжатия Kombu.
По умолчанию отправляются несжатые сообщения.
task_protocol
¶
По умолчанию: 2 (начиная с версии 4.0).
Установка версии протокола сообщения задачи по умолчанию, используемого для отправки задач. Поддерживаются протоколы: 1 и 2.
Протокол 2 поддерживается версиями 3.1.24 и 4.x+.
task_serializer
¶
По умолчанию: "json"
(начиная с версии 4.0, ранее: pickle).
Строка, определяющая используемый по умолчанию метод сериализации. Это может быть json (по умолчанию), pickle, yaml, msgpack или любой пользовательский метод сериализации, который был зарегистрирован с помощью kombu.serialization.registry
.
См.также
task_publish_retry
¶
Добавлено в версии 2.2.
По умолчанию: Включено.
Определяет, будут ли сообщения задачи публикации повторяться в случае потери соединения или других ошибок соединения. См. также task_publish_retry_policy
.
task_publish_retry_policy
¶
Добавлено в версии 2.2.
По умолчанию: См. Повторная отправка сообщения.
Определяет политику по умолчанию при повторной попытке публикации сообщения задачи в случае потери соединения или других ошибок соединения.
Настройки выполнения задачи¶
task_always_eager
¶
По умолчанию: Отключено.
Если это True
, все задачи будут выполняться локально, блокируясь до тех пор, пока задача не вернется. apply_async()
и Task.delay()
вернут экземпляр EagerResult
, который эмулирует API и поведение AsyncResult
, за исключением того, что результат уже оценен.
То есть задания будут выполняться локально, а не отправляться в очередь.
task_eager_propagates
¶
По умолчанию: Отключено.
Если это значение True
, выполняемые с нетерпением задачи (применяемые task.apply(), или когда включена настройка task_always_eager
), будут распространять исключения.
Это то же самое, что всегда выполнять apply()
с throw=True
.
task_store_eager_result
¶
Добавлено в версии 5.1.
По умолчанию: Отключено.
Если это значение равно True
и task_always_eager
равно True
и task_ignore_result
равно False
, результаты нетерпеливо выполняемых задач будут сохранены в бэкенде.
По умолчанию, даже если task_always_eager
установлено в True
и task_ignore_result
установлено в False
, результат не будет сохранен.
task_remote_tracebacks
¶
По умолчанию: Отключено.
Если включено, результаты выполнения задачи будут включать стек рабочих при повторном поднятии ошибок задачи.
Для этого требуется библиотека tblib, которая может быть установлена с помощью pip:
$ pip install celery[tblib]
Информацию о совмещении нескольких требований к расширению см. в Пакеты.
task_ignore_result
¶
По умолчанию: Отключено.
Хранить ли значения возврата задачи или нет (надгробные камни). Если вы все же хотите хранить ошибки, а не успешные значения возврата, вы можете установить task_store_errors_even_if_ignored
.
task_store_errors_even_if_ignored
¶
По умолчанию: Отключено.
Если установлено, рабочий сохраняет все ошибки задачи в хранилище результатов, даже если Task.ignore_result
включено.
task_track_started
¶
По умолчанию: Отключено.
Если True
, задача будет сообщать о своем статусе как «запущена», когда задача выполняется рабочим. Значение по умолчанию False
, так как обычное поведение заключается в том, чтобы не сообщать о таком уровне детализации. Задачи либо ожидают выполнения, либо завершены, либо ожидают повторной попытки. Наличие состояния „запущено“ может быть полезно, когда есть долго выполняющиеся задачи и есть необходимость сообщить, какая задача запущена в данный момент.
task_time_limit
¶
По умолчанию: Без ограничения времени.
Предельное время выполнения задачи в секундах. При превышении этого лимита рабочий, обрабатывающий задание, будет убит и заменен новым.
task_soft_time_limit
¶
По умолчанию: Нет мягкого ограничения времени.
Ограничение времени мягкой работы задачи в секундах.
Исключение SoftTimeLimitExceeded
будет поднято при превышении этого значения. Например, задача может перехватить его, чтобы очистить до наступления жесткого лимита времени:
from celery.exceptions import SoftTimeLimitExceeded
@app.task
def mytask():
try:
return do_work()
except SoftTimeLimitExceeded:
cleanup_in_a_hurry()
task_acks_late
¶
По умолчанию: Отключено.
Late ack означает, что сообщения задачи будут подтверждены после выполнения задачи, а не только перед (поведение по умолчанию).
См.также
ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ: Следует ли мне использовать retry или acks_late?.
task_acks_on_failure_or_timeout
¶
По умолчанию: Включено
Если эта функция включена, сообщения для всех задач будут подтверждены, даже если они потерпели неудачу или закончились по времени.
Настройка этого параметра применяется только к заданиям, квитируемым после их выполнения, и только если включена опция task_acks_late
.
task_reject_on_worker_lost
¶
По умолчанию: Отключено.
Даже если включено task_acks_late
, рабочий будет квитировать задания, когда выполняющий их рабочий процесс внезапно завершается или получает сигнал (например, KILL
/INT
и т.д.).
Установка этого значения в true позволяет повторно зарегистрировать сообщение, чтобы задание было выполнено снова тем же рабочим или другим рабочим.
Предупреждение
Включение этой функции может привести к зацикливанию сообщений; убедитесь, что вы знаете, что делаете.
task_default_rate_limit
¶
По умолчанию: Нет ограничения скорости.
Глобальный предел скорости по умолчанию для задач.
Это значение используется для задач, для которых не установлено пользовательское ограничение скорости.
См.также
Настройка:worker_disable_rate_limits позволяет отключить все ограничения скорости.
Настройки бэкенда результатов задачи¶
result_backend
¶
По умолчанию: По умолчанию бэкенд результатов не включен.
Бэкэнд, используемый для хранения результатов задач (надгробий). Может быть одним из следующих:
rpc
Отправляйте результаты обратно в виде сообщений AMQP См. Настройки бэкенда RPC.
database
Используйте реляционную базу данных, поддерживаемую SQLAlchemy. См. Настройки бэкенда базы данных.
redis
Используйте Redis для хранения результатов. См. Настройки бэкенда Redis.
cache
Используйте Memcached для хранения результатов. См. Настройки бэкенда кэша.
- mongodb
Используйте MongoDB для хранения результатов. См. Настройки бэкенда MongoDB.
cassandra
Используйте Cassandra для хранения результатов. См. Настройки бэкенда Cassandra.
elasticsearch
Используйте Elasticsearch для хранения результатов. См. Настройки бэкенда Elasticsearch.
ironcache
Используйте IronCache для хранения результатов. См. Настройки бэкенда IronCache.
couchbase
Используйте Couchbase для хранения результатов. См. Настройки бэкенда Couchbase.
arangodb
Используйте ArangoDB для хранения результатов. См. Настройки бэкенда ArangoDB.
couchdb
Используйте CouchDB для хранения результатов. См. Настройки бэкенда CouchDB.
cosmosdbsql (experimental)
Используйте CosmosDB PaaS для хранения результатов. См. Настройки бэкенда CosmosDB (экспериментально).
filesystem
Используйте общий каталог для хранения результатов. См. Настройки бэкенда файловой системы.
consul
Используйте функцию Consul K/V store для сохранения результатов См. Настройки бэкенда магазина Consul K/V.
azureblockblob
Используйте хранилище AzureBlockBlob PaaS для хранения результатов См. Настройки бэкенда Azure Block Blob.
s3
Используйте S3 для сохранения результатов См. Настройки бэкенда S3.
result_backend_always_retry
¶
По умолчанию: False
Если включено, бэкенд будет пытаться повторить попытку при возникновении восстанавливаемых исключений вместо того, чтобы распространять исключение. При этом будет использоваться экспоненциальное время ожидания между двумя повторными попытками.
result_backend_max_sleep_between_retries_ms
¶
По умолчанию: 10000
Определяет максимальное время сна между двумя повторными операциями бэкенда.
result_backend_base_sleep_between_retries_ms
¶
По умолчанию: 10
Определяет базовое время сна между двумя повторными операциями бэкенда.
result_backend_max_retries
¶
По умолчанию: Inf
Это максимальное количество повторных попыток в случае восстанавливаемых исключений.
result_backend_transport_options
¶
По умолчанию: {}
(пустое отображение).
Набор дополнительных опций, передаваемых базовому транспорту.
Поддерживаемые опции (если таковые имеются) см. в руководстве пользователя вашего транспорта.
Пример установки таймаута видимости (поддерживается транспортами Redis и SQS):
result_backend_transport_options = {'visibility_timeout': 18000} # 5 hours
result_serializer
¶
По умолчанию: json
с версии 4.0 (ранее: pickle).
Формат сериализации результатов.
Информацию о поддерживаемых форматах сериализации смотрите в Сериализаторы.
result_compression
¶
По умолчанию: Нет сжатия.
Необязательный метод сжатия, используемый для результатов задачи. Поддерживает те же параметры, что и параметр task_compression
.
result_extended
¶
По умолчанию: False
Позволяет записывать расширенные атрибуты результата задачи (имя, args, kwargs, worker, retries, queue, delivery_info) в бэкенд.
result_expires
¶
По умолчанию: Истекает через 1 день.
Время (в секундах или объект timedelta
), в течение которого будут удалены надгробные камни после сохранения задания.
Встроенная периодическая задача удалит результаты по истечении этого времени (celery.backend_cleanup
), при условии, что включено celery beat
. Задача запускается ежедневно в 4 утра.
Значение None
или 0 означает, что результаты никогда не истекут (в зависимости от спецификаций бэкенда).
Примечание
На данный момент это работает только с бэкендами AMQP, базы данных, кэша, Couchbase и Redis.
При использовании бэкенда базы данных, celery beat
должен быть запущен, чтобы результаты были просрочены.
result_cache_max
¶
По умолчанию: По умолчанию отключено.
Включает клиентское кэширование результатов.
Это может быть полезно для старого устаревшего бэкенда „amqp“, где результат становится недоступным, как только один экземпляр результата потребляет его.
Это общее количество результатов, которые необходимо кэшировать, прежде чем старые результаты будут удалены. Значение 0 или None означает отсутствие ограничений, а значение -1
отключает кэш.
По умолчанию отключен.
result_chord_join_timeout
¶
По умолчанию: 3.0.
Таймаут в секундах (int/float) при соединении результатов группы в пределах аккорда.
result_chord_retry_interval
¶
По умолчанию: 1.0.
Интервал по умолчанию для повторных попыток выполнения аккордных задач.
Настройки бэкенда базы данных¶
Примеры URL-адресов баз данных¶
Для использования бэкенда базы данных необходимо настроить параметр result_backend
с URL подключения и префиксом db+
:
result_backend = 'db+scheme://user:password@host:port/dbname'
Примеры:
# sqlite (filename)
result_backend = 'db+sqlite:///results.sqlite'
# mysql
result_backend = 'db+mysql://scott:tiger@localhost/foo'
# postgresql
result_backend = 'db+postgresql://scott:tiger@localhost/mydatabase'
# oracle
result_backend = 'db+oracle://scott:tiger@127.0.0.1:1521/sidname'
Пожалуйста, смотрите Supported Databases для таблицы поддерживаемых баз данных, и Connection String для получения дополнительной информации о строках подключения (это часть URI, которая идет после префикса db+
).
database_engine_options
¶
По умолчанию: {}
(пустое отображение).
Для указания дополнительных опций движка базы данных SQLAlchemy можно использовать параметр database_engine_options
:
# echo enables verbose logging from SQLAlchemy.
app.conf.database_engine_options = {'echo': True}
database_short_lived_sessions
¶
По умолчанию: По умолчанию отключено.
По умолчанию короткоживущие сессии отключены. Если их включить, они могут резко снизить производительность, особенно в системах, обрабатывающих большое количество задач. Эта опция полезна для рабочих систем с низким трафиком, которые испытывают ошибки в результате того, что кэшированные соединения с базой данных становятся несвежими из-за неактивности. Например, периодические ошибки типа (OperationalError) (2006, „MySQL server has gone away“) могут быть исправлены включением короткоживущих сессий. Эта опция влияет только на бэкенд базы данных.
database_table_schemas
¶
По умолчанию: {}
(пустое отображение).
Когда SQLAlchemy настроен в качестве бэкенда результатов, Celery автоматически создает две таблицы для хранения метаданных результатов для задач. Эта настройка позволяет вам настроить схему таблиц:
# use custom schema for the database result backend.
database_table_schemas = {
'task': 'celery',
'group': 'celery',
}
database_table_names
¶
По умолчанию: {}
(пустое отображение).
Когда SQLAlchemy настроен в качестве бэкенда результатов, Celery автоматически создает две таблицы для хранения метаданных результатов для задач. Эта настройка позволяет вам настроить имена таблиц:
# use custom table names for the database result backend.
database_table_names = {
'task': 'myapp_taskmeta',
'group': 'myapp_groupmeta',
}
Настройки бэкенда RPC¶
result_persistent
¶
По умолчанию: По умолчанию отключено (переходные сообщения).
Если установлено значение True
, сообщения результата будут постоянными. Это означает, что сообщения не будут потеряны после перезапуска брокера.
Пример конфигурации¶
result_backend = 'rpc://'
result_persistent = False
Примечание: использование этого бэкенда может вызвать повышение celery.backends.rpc.BacklogLimitExceeded
, если надгробие задачи слишком старое.
Например.
for i in range(10000):
r = debug_task.delay()
print(r.state) # this would raise celery.backends.rpc.BacklogLimitExceeded
Настройки бэкенда кэша¶
Примечание
Бэкенд кэша поддерживает библиотеки pylibmc и << 1 >>>. Последняя используется только в том случае, если не установлена python-memcached.
Использование одного сервера Memcached:
result_backend = 'cache+memcached://127.0.0.1:11211/'
Использование нескольких серверов Memcached:
result_backend = """
cache+memcached://172.19.26.240:11211;172.19.26.242:11211/
""".strip()
Бэкэнд «память» хранит кэш только в памяти:
result_backend = 'cache'
cache_backend = 'memory'
cache_backend_options
¶
По умолчанию: {}
(пустое отображение).
Вы можете установить параметры pylibmc, используя настройку cache_backend_options
:
cache_backend_options = {
'binary': True,
'behaviors': {'tcp_nodelay': True},
}
cache_backend
¶
Этот параметр больше не используется во встроенных бэкендах celery, поскольку теперь можно указать бэкенд кэша напрямую в параметре result_backend
.
Примечание
Библиотека django-celery-results - Использование Django ORM/Cache в качестве бэкенда результатов использует cache_backend
для выбора кэшей django.
Настройки бэкенда MongoDB¶
Примечание
Для бэкенда MongoDB требуется библиотека pymongo
: http://github.com/mongodb/mongo-python-driver/tree/master.
mongodb_backend_settings¶
Это диктант, поддерживающий следующие ключи:
- база данных
Имя базы данных для подключения. По умолчанию имеет значение
celery
.
- коллекция taskmeta_collection
Имя коллекции для хранения метаданных задачи. По умолчанию имеет значение
celery_taskmeta
.
- максимальный размер_пула
Передается как max_pool_size в конструктор PyMongo’s Connection или MongoClient. Это максимальное количество TCP-соединений, которые необходимо держать открытыми для MongoDB в данный момент времени. Если открытых соединений больше, чем max_pool_size, сокеты будут закрыты, когда они освободятся. По умолчанию равно 10.
варианты
Дополнительные ключевые аргументы для передачи в конструктор соединения mongodb. Список поддерживаемых аргументов приведен в документации
pymongo
.
Пример конфигурации¶
result_backend = 'mongodb://localhost:27017/'
mongodb_backend_settings = {
'database': 'mydb',
'taskmeta_collection': 'my_taskmeta_collection',
}
Настройки бэкенда Redis¶
Настройка URL-адреса бэкенда¶
Примечание
Для бэкенда Redis требуется библиотека redis.
Для установки этого пакета используйте pip:
$ pip install celery[redis]
Информацию о совмещении нескольких требований к расширению см. в Пакеты.
Этот бэкенд требует, чтобы параметр result_backend
был установлен на Redis или Redis over TLS URL:
result_backend = 'redis://username:password@host:port/db'
Например:
result_backend = 'redis://localhost/0'
это то же самое, что:
result_backend = 'redis://'
Используйте протокол rediss://
для подключения к redis через TLS:
result_backend = 'rediss://username:password@host:port/db?ssl_cert_reqs=required'
Обратите внимание, что строка ssl_cert_reqs
должна быть одной из required
, optional
или none
(хотя, для обратной совместимости, строка также может быть одной из CERT_REQUIRED
, CERT_OPTIONAL
, CERT_NONE
).
Если необходимо использовать сокетное соединение Unix, URL должен быть в формате::
result_backend = 'socket:///path/to/redis.sock'
Поля URL определяются следующим образом:
username
Добавлено в версии 5.1.0.
Имя пользователя, используемое для подключения к базе данных.
Обратите внимание, что это поддерживается только в Redis>=6.0 и при установленном py-redis>=3.4.0.
Если вы используете более старую версию базы данных или более старую версию клиента, вы можете опустить имя пользователя:
result_backend = 'redis://:password@host:port/db'
password
Пароль, используемый для подключения к базе данных.
host
Имя хоста или IP-адрес сервера Redis (например, localhost).
port
Порт для подключения к серверу Redis. По умолчанию - 6379.
db
Номер базы данных для использования. По умолчанию - 0. db может включать необязательную ведущую косую черту.
При использовании TLS-соединения (протокол rediss://
) в качестве параметров запроса можно передавать все значения в broker_use_ssl
. Пути к сертификатам должны быть закодированы в URL, и ssl_cert_reqs
является обязательным. Пример:
result_backend = 'rediss://:password@host:port/db?\
ssl_cert_reqs=required\
&ssl_ca_certs=%2Fvar%2Fssl%2Fmyca.pem\ # /var/ssl/myca.pem
&ssl_certfile=%2Fvar%2Fssl%2Fredis-server-cert.pem\ # /var/ssl/redis-server-cert.pem
&ssl_keyfile=%2Fvar%2Fssl%2Fprivate%2Fworker-key.pem' # /var/ssl/private/worker-key.pem
Обратите внимание, что строка ssl_cert_reqs
должна быть одной из required
, optional
или none
(хотя, для обратной совместимости, строка также может быть одной из CERT_REQUIRED
, CERT_OPTIONAL
, CERT_NONE
).
Добавлено в версии 5.1.0.
redis_backend_health_check_interval
¶
По умолчанию: Не настроено
Бэкенд Redis поддерживает проверку работоспособности. Это значение должно быть задано как целое число, которое представляет собой количество секунд между проверками здоровья. Если во время проверки здоровья возникнет ошибка ConnectionError или TimeoutError, соединение будет восстановлено, а команда повторена ровно один раз.
redis_backend_use_ssl
¶
По умолчанию: Отключено.
Бэкэнд Redis поддерживает SSL. Это значение должно быть задано в виде словаря. Допустимые пары ключ-значение те же, что и в подразделе redis
в разделе broker_use_ssl
.
redis_max_connections
¶
По умолчанию: Без ограничения.
Максимальное количество соединений, доступных в пуле соединений Redis, используемом для отправки и получения результатов.
Предупреждение
Redis выдаст сообщение ConnectionError, если количество одновременных соединений превысит максимальное значение.
redis_socket_connect_timeout
¶
Добавлено в версии 4.0.1.
По умолчанию: None
Таймаут сокета для соединений с Redis от бэкенда результатов в секундах (int/float)
redis_socket_timeout
¶
По умолчанию: 120,0 секунд.
Таймаут сокета для операций чтения/записи на сервер Redis в секундах (int/float), используется бэкендом результатов redis.
redis_retry_on_timeout
¶
Добавлено в версии 4.4.1.
По умолчанию: False
Для повторения операций чтения/записи при ошибке TimeoutError на сервере Redis, используется бэкендом результатов Redis. Не следует устанавливать эту переменную, если используется соединение с Redis через unix-сокет.
redis_socket_keepalive
¶
Добавлено в версии 4.4.1.
По умолчанию: False
Socket TCP keepalive для поддержания соединений с сервером Redis, используется бэкендом результатов redis.
Настройки бэкенда Cassandra¶
Примечание
Этот драйвер бэкенда Cassandra требует cassandra-driver.
Для установки используйте pip:
$ pip install celery[cassandra]
Информацию о совмещении нескольких требований к расширению см. в Пакеты.
Этот бэкенд требует установки следующих директив конфигурации.
cassandra_servers
¶
По умолчанию: []
(пустой список).
Список host
серверов Cassandra. Например:
cassandra_servers = ['localhost']
cassandra_port
¶
По умолчанию: 9042.
Порт для связи с серверами Cassandra.
cassandra_keyspace
¶
По умолчанию: Нет.
Ключевое пространство, в котором будут храниться результаты. Например:
cassandra_keyspace = 'tasks_keyspace'
cassandra_table
¶
По умолчанию: Нет.
Таблица (семейство столбцов), в которой будут храниться результаты. Например:
cassandra_table = 'tasks'
cassandra_read_consistency
¶
По умолчанию: Нет.
Используемая консистенция чтения. Значения могут быть ONE
, TWO
, THREE
, QUORUM
, ALL
, LOCAL_QUORUM
, EACH_QUORUM
, LOCAL_ONE
.
cassandra_write_consistency
¶
По умолчанию: Нет.
Используемая консистенция записи. Значения могут быть ONE
, TWO
, THREE
, QUORUM
, ALL
, LOCAL_QUORUM
, EACH_QUORUM
, LOCAL_ONE
.
cassandra_entry_ttl
¶
По умолчанию: Нет.
Время жизни для записей состояния. Они истекут и будут удалены через столько секунд после добавления. Значение None
(по умолчанию) означает, что они никогда не истекут.
cassandra_auth_provider
¶
По умолчанию: None
.
Класс AuthProvider в модуле cassandra.auth
для использования. Значения могут быть PlainTextAuthProvider
или SaslAuthProvider
.
cassandra_auth_kwargs
¶
По умолчанию: {}
(пустое отображение).
Именованные аргументы для передачи провайдеру аутентификации. Например:
cassandra_auth_kwargs = {
username: 'cassandra',
password: 'cassandra'
}
cassandra_options
¶
По умолчанию: {}
(пустое отображение).
Именованные аргументы для передачи в класс cassandra.cluster
.
cassandra_options = {
'cql_version': '3.2.1'
'protocol_version': 3
}
Пример конфигурации¶
cassandra_servers = ['localhost']
cassandra_keyspace = 'celery'
cassandra_table = 'tasks'
cassandra_read_consistency = 'ONE'
cassandra_write_consistency = 'ONE'
cassandra_entry_ttl = 86400
Настройки бэкенда S3¶
Примечание
Этот драйвер бэкенда s3 требует s3.
Для установки используйте s3:
$ pip install celery[s3]
Информацию о совмещении нескольких требований к расширению см. в Пакеты.
Этот бэкенд требует установки следующих директив конфигурации.
s3_access_key_id
¶
По умолчанию: Нет.
Идентификатор ключа доступа s3. Например:
s3_access_key_id = 'acces_key_id'
s3_secret_access_key
¶
По умолчанию: Нет.
Секретный ключ доступа s3. Например:
s3_secret_access_key = 'acces_secret_access_key'
s3_bucket
¶
По умолчанию: Нет.
Имя ведра s3. Например:
s3_bucket = 'bucket_name'
s3_base_path
¶
По умолчанию: Нет.
Базовый путь в ведре s3 для хранения ключей результатов. Например:
s3_base_path = '/prefix'
s3_endpoint_url
¶
По умолчанию: Нет.
Пользовательский url конечной точки s3. Используйте его для подключения к собственному бэкенду, совместимому с s3 (Ceph, Scality…). Например:
s3_endpoint_url = 'https://.s3.custom.url'
s3_region
¶
По умолчанию: Нет.
Регион s3 aws. Например:
s3_region = 'us-east-1'
Пример конфигурации¶
s3_access_key_id = 's3-access-key-id'
s3_secret_access_key = 's3-secret-access-key'
s3_bucket = 'mybucket'
s3_base_path = '/celery_result_backend'
s3_endpoint_url = 'https://endpoint_url'
Настройки бэкенда Azure Block Blob¶
Чтобы использовать AzureBlockBlob в качестве бэкенда результатов, вам просто нужно настроить параметр result_backend
с правильным URL.
Требуемый формат URL-адреса - azureblockblob://
, за которым следует строка подключения к хранилищу. Строку подключения к хранилищу можно найти в панели Access Keys
ресурса учетной записи хранилища в Azure Portal.
Пример конфигурации¶
result_backend = 'azureblockblob://DefaultEndpointsProtocol=https;AccountName=somename;AccountKey=Lou...bzg==;EndpointSuffix=core.windows.net'
azureblockblob_container_name
¶
По умолчанию: сельдерей.
Имя для контейнера хранения, в котором будут храниться результаты.
azureblockblob_base_path
¶
Добавлено в версии 5.1.
По умолчанию: Нет.
Базовый путь в контейнере хранения, используемый для хранения ключей результатов. Например:
azureblockblob_base_path = 'prefix/'
azureblockblob_retry_initial_backoff_sec
¶
По умолчанию: 2.
Начальный интервал отката, в секундах, для первой повторной попытки. Последующие повторные попытки выполняются по экспоненциальной стратегии.
azureblockblob_retry_increment_base
¶
По умолчанию: 2.
azureblockblob_retry_max_attempts
¶
По умолчанию: 3.
Максимальное количество повторных попыток.
Настройки бэкенда Elasticsearch¶
Чтобы использовать Elasticsearch в качестве бэкенда результатов, вам просто нужно настроить параметр result_backend
с правильным URL.
Пример конфигурации¶
result_backend = 'elasticsearch://example.com:9200/index_name/doc_type'
elasticsearch_retry_on_timeout
¶
По умолчанию: False
Должен ли таймаут вызывать повторную попытку на другом узле?
elasticsearch_max_retries
¶
По умолчанию: 3.
Максимальное количество повторных попыток перед распространением исключения.
elasticsearch_timeout
¶
По умолчанию: 10,0 секунд.
Глобальный таймаут, используемый бэкендом результатов elasticsearch.
elasticsearch_save_meta_as_text
¶
По умолчанию: True
Следует сохранять метаданные в виде текста или в формате json. Результат всегда сериализуется как текст.
Настройки бэкенда AWS DynamoDB¶
Примечание
Для бэкенда Dynamodb требуется библиотека boto3.
Для установки этого пакета используйте pip:
$ pip install celery[dynamodb]
Информацию о совмещении нескольких требований к расширению см. в Пакеты.
Предупреждение
Бэкенд Dynamodb не совместим с таблицами, в которых определен ключ сортировки.
Если вы хотите запрашивать таблицу результатов на основе чего-то другого, чем ключ раздела, определите вместо этого глобальный вторичный индекс (GSI).
Этот бэкенд требует, чтобы параметр result_backend
был установлен на URL DynamoDB:
result_backend = 'dynamodb://aws_access_key_id:aws_secret_access_key@region:port/table?read=n&write=m'
Например, указав регион AWS и имя таблицы:
result_backend = 'dynamodb://@us-east-1/celery_results'
или получить параметры конфигурации AWS из среды, используя имя таблицы по умолчанию (celery
) и указав пропускную способность для чтения и записи:
result_backend = 'dynamodb://@/?read=5&write=5'
или используя downloadable version DynamoDB locally:
result_backend = 'dynamodb://@localhost:8000'
или используя загружаемую версию или другой сервис с соответствующим API, развернутый на любом хосте:
result_backend = 'dynamodb://@us-east-1'
dynamodb_endpoint_url = 'http://192.168.0.40:8000'
Поля URL DynamoDB в result_backend
определяются следующим образом:
aws_access_key_id & aws_secret_access_key
region
Область AWS, например,
us-east-1
илиlocalhost
для Downloadable Version. Варианты определения см. в библиотеке boto3 documentation.port
Порт прослушивания локального экземпляра DynamoDB, если вы используете загружаемую версию. Если вы не указали параметр
region
какlocalhost
, установка этого параметра не имеет эффекта.table
Имя таблицы для использования. По умолчанию
celery
. Информацию о допустимых символах и длине см. в DynamoDB Naming Rules.read & write
Единицы емкости для чтения и записи для созданной таблицы DynamoDB. По умолчанию
1
как для чтения, так и для записи. Более подробную информацию можно найти в Provisioned Throughput documentation.ttl_seconds
Время жизни (в секундах) для результатов до их истечения. По умолчанию результаты не истекают, при этом параметры Time to Live таблицы DynamoDB остаются нетронутыми. Если
ttl_seconds
имеет положительное значение, результаты истекут через указанное количество секунд. Установкаttl_seconds
в отрицательное значение означает, что результаты не будут уничтожаться, а также активно отключается настройка Time to Live таблицы DynamoDB. Обратите внимание, что попытка изменить параметр Time to Live таблицы несколько раз подряд приведет к ошибке дросселирования. Более подробную информацию можно найти в разделе DynamoDB TTL documentation.
Настройки бэкенда IronCache¶
Примечание
Для бэкенда IronCache требуется библиотека iron_celery:
Для установки этого пакета используйте pip:
$ pip install iron_celery
IronCache настраивается через URL, указанный в result_backend
, например:
result_backend = 'ironcache://project_id:token@'
Или изменить имя кэша:
ironcache:://project_id:token@/awesomecache
Для получения дополнительной информации см.: https://github.com/iron-io/iron_celery
Настройки бэкенда Couchbase¶
Примечание
Для бэкенда Couchbase требуется библиотека couchbase.
Для установки этого пакета используйте pip:
$ pip install celery[couchbase]
Инструкции по объединению нескольких требований к расширению см. в Пакеты.
Этот бэкенд можно настроить с помощью параметра result_backend
, установленного на URL Couchbase:
result_backend = 'couchbase://username:password@host:port/bucket'
couchbase_backend_settings
¶
По умолчанию: {}
(пустое отображение).
Это диктант, поддерживающий следующие ключи:
host
Имя хоста сервера Couchbase. По умолчанию имеет значение
localhost
.port
Порт, который прослушивает сервер Couchbase. По умолчанию имеет значение
8091
.bucket
Ведро по умолчанию, в которое записывается сервер Couchbase. По умолчанию имеет значение
default
.username
Имя пользователя для аутентификации на сервере Couchbase (необязательно).
password
Пароль для аутентификации на сервере Couchbase (необязательно).
Настройки бэкенда ArangoDB¶
Примечание
Для бэкенда ArangoDB требуется библиотека pyArango.
Для установки этого пакета используйте pip:
$ pip install celery[arangodb]
Инструкции по объединению нескольких требований к расширению см. в Пакеты.
Этот бэкенд может быть настроен с помощью параметра result_backend
, установленного на URL ArangoDB:
result_backend = 'arangodb://username:password@host:port/database/collection'
arangodb_backend_settings
¶
По умолчанию: {}
(пустое отображение).
Это диктант, поддерживающий следующие ключи:
host
Имя хоста сервера ArangoDB. По умолчанию имеет значение
localhost
.port
Порт, на котором прослушивается сервер ArangoDB. По умолчанию имеет значение
8529
.database
База данных по умолчанию, в которую производится запись на сервере ArangoDB. По умолчанию имеет значение
celery
.collection
Коллекция по умолчанию в базе данных серверов ArangoDB, в которую производится запись. По умолчанию имеет значение
celery
.username
Имя пользователя для аутентификации на сервере ArangoDB (необязательно).
password
Пароль для аутентификации на сервере ArangoDB (необязательно).
Настройки бэкенда CosmosDB (экспериментально)¶
Чтобы использовать CosmosDB в качестве бэкенда результатов, вам просто нужно настроить параметр result_backend
с правильным URL.
Пример конфигурации¶
result_backend = 'cosmosdbsql://:{InsertAccountPrimaryKeyHere}@{InsertAccountNameHere}.documents.azure.com'
cosmosdbsql_database_name
¶
По умолчанию: celerydb.
Имя базы данных, в которой будут храниться результаты.
cosmosdbsql_collection_name
¶
По умолчанию: целекоксиб.
Имя коллекции, в которой будут храниться результаты.
cosmosdbsql_consistency_level
¶
По умолчанию: Сессия.
Представляет уровни согласованности, поддерживаемые для клиентских операций Azure Cosmos DB.
Уровни согласованности в порядке возрастания силы следующие: Strong, BoundedStaleness, Session, ConsistentPrefix и Eventual.
cosmosdbsql_max_retry_attempts
¶
По умолчанию: 9.
Максимальное количество повторных попыток для запроса.
cosmosdbsql_max_retry_wait_time
¶
По умолчанию: 30.
Максимальное время ожидания в секундах для ожидания запроса, пока происходят повторные попытки.
Настройки бэкенда CouchDB¶
Примечание
Для бэкенда CouchDB требуется библиотека pycouchdb:
Для установки этого пакета Couchbase используйте pip:
$ pip install celery[couchdb]
Информацию о совмещении нескольких требований к расширению см. в Пакеты.
Этот бэкенд может быть настроен с помощью параметра result_backend
, установленного на URL CouchDB:
result_backend = 'couchdb://username:password@host:port/container'
URL формируется из следующих частей:
username
Имя пользователя для аутентификации на сервере CouchDB (необязательно).
password
Пароль для аутентификации на сервере CouchDB (необязательно).
host
Имя хоста сервера CouchDB. По умолчанию имеет значение
localhost
.port
Порт, на котором прослушивается сервер CouchDB. По умолчанию имеет значение
8091
.container
Контейнер по умолчанию, в который записывается сервер CouchDB. По умолчанию имеет значение
default
.
Настройки бэкенда файловой системы¶
Этот бэкэнд может быть настроен с помощью URL файла, например:
CELERY_RESULT_BACKEND = 'file:///var/celery/results'
Сконфигурированный каталог должен быть общим и доступным для записи всем серверам, использующим бэкэнд.
Если вы пробуете Celery на одной системе, вы можете просто использовать бэкэнд без дополнительной настройки. Для больших кластеров вы можете использовать NFS, GlusterFS, CIFS, HDFS (используя FUSE), или любую другую файловую систему.
Настройки бэкенда магазина Consul K/V¶
Бэкэнд Consul можно настроить с помощью URL-адреса, например:
CELERY_RESULT_BACKEND = „consul://localhost:8500/“
Бэкэнд будет хранить результаты в хранилище K/V в Consul в виде отдельных ключей.
Бэкэнд поддерживает автоматическое истечение срока действия результатов с использованием TTL в Consul.
Маршрутизация сообщений¶
task_queues
¶
По умолчанию: None
(очередь взята из настроек очереди по умолчанию).
Большинство пользователей не захотят указывать этот параметр и предпочтут использовать automatic routing facilities.
Если вы действительно хотите настроить расширенную маршрутизацию, этот параметр должен представлять собой список kombu.Queue
объектов, из которых будет потреблять рабочий.
Обратите внимание, что рабочие очереди могут быть отменены с помощью опции -Q
, или отдельные очереди из этого списка (по имени) могут быть исключены с помощью опции -X
.
Также смотрите Основы для получения дополнительной информации.
По умолчанию ключ очереди/обмена/привязки имеет значение celery
, а тип обмена direct
.
См. также task_routes
task_routes
¶
По умолчанию: None
.
Список маршрутизаторов или один маршрутизатор, используемый для маршрутизации заданий в очереди. При определении конечного пункта назначения задачи маршрутизаторы рассматриваются по порядку.
Маршрутизатор может быть указан как:
Функция с сигнатурой
(name, args, kwargs, options, task=None, **kwargs)
Строка, указывающая путь к функции маршрутизатора.
- Дикт, содержащий спецификацию маршрутизатора:
Будет преобразован в экземпляр
celery.routes.MapRoute
.
- Список кортежей
(pattern, route)
: Будет преобразован в экземпляр
celery.routes.MapRoute
.
- Список кортежей
Примеры:
task_routes = {
'celery.ping': 'default',
'mytasks.add': 'cpu-bound',
'feed.tasks.*': 'feeds', # <-- glob pattern
re.compile(r'(image|video)\.tasks\..*'): 'media', # <-- regex
'video.encode': {
'queue': 'video',
'exchange': 'media',
'routing_key': 'media.video.encode',
},
}
task_routes = ('myapp.tasks.route_task', {'celery.ping': 'default})
Где myapp.tasks.route_task
может быть:
def route_task(self, name, args, kwargs, options, task=None, **kw):
if task == 'celery.ping':
return {'queue': 'default'}
route_task
может вернуть строку или dict. Строка означает, что это имя очереди в task_queues
, а dict означает, что это пользовательский маршрут.
При отправке заданий маршрутизаторы просматриваются по порядку. Первый маршрутизатор, который не возвращает None
, является маршрутом, который следует использовать. Затем параметры сообщения объединяются с найденными параметрами маршрута, при этом параметры задания имеют приоритет.
Пример, если apply_async()
имеет такие аргументы:
Task.apply_async(immediate=False, exchange='video',
routing_key='video.compress')
и маршрутизатор возвращается:
{'immediate': True, 'exchange': 'urgent'}
окончательные варианты сообщений будут такими:
immediate=False, exchange='video', routing_key='video.compress'
(и любые параметры сообщения по умолчанию, определенные в классе Task
)
Значения, определенные в task_routes
, имеют приоритет над значениями, определенными в task_queues
, при объединении этих двух значений.
Со следующими настройками:
task_queues = {
'cpubound': {
'exchange': 'cpubound',
'routing_key': 'cpubound',
},
}
task_routes = {
'tasks.add': {
'queue': 'cpubound',
'routing_key': 'tasks.add',
'serializer': 'json',
},
}
Окончательные варианты маршрутизации для tasks.add
будут такими:
{'exchange': 'cpubound',
'routing_key': 'tasks.add',
'serializer': 'json'}
Дополнительные примеры см. в разделе Маршрутизаторы.
task_queue_max_priority
¶
- брокеры:
RabbitMQ
По умолчанию: None
.
task_default_priority
¶
- брокеры:
RabbitMQ, Redis
По умолчанию: None
.
task_inherit_parent_priority
¶
- брокеры:
RabbitMQ
По умолчанию: False
.
Если включено, дочерние задачи будут наследовать приоритет родительской задачи.
# The last task in chain will also have priority set to 5.
chain = celery.chain(add.s(2) | add.s(2).set(priority=5) | add.s(3))
Наследование приоритетов также работает при вызове дочерних задач из родительской задачи с delay или apply_async.
worker_direct
¶
По умолчанию: Отключено.
Эта опция позволяет каждому работнику иметь выделенную очередь, чтобы задания можно было направлять конкретным работникам.
Имя очереди для каждого рабочего автоматически генерируется на основе имени хоста рабочего и суффикса .dq
, используя обмен C.dq
.
Например, имя очереди для рабочего с именем узла w1@example.com
становится:
w1@example.com.dq
Затем вы можете направить задание на задание, указав имя хоста в качестве ключа маршрутизации и обмен C.dq
:
task_routes = {
'tasks.add': {'exchange': 'C.dq', 'routing_key': 'w1@example.com'}
}
task_create_missing_queues
¶
По умолчанию: Включено.
Если включено (по умолчанию), все указанные очереди, которые не определены в task_queues
, будут созданы автоматически. См. Автоматическая маршрутизация.
task_default_queue
¶
По умолчанию: "celery"
.
Имя очереди по умолчанию, используемой .apply_async, если у сообщения нет маршрута или не указана пользовательская очередь.
Эта очередь должна быть указана в task_queues
. Если task_queues
не указан, то он автоматически создается, содержащий одну запись очереди, где это имя используется в качестве имени этой очереди.
См.также
task_default_exchange
¶
По умолчанию: Используется значение, установленное для task_default_queue
.
Имя обмена по умолчанию, который будет использоваться, если для ключа не указан пользовательский обмен в настройке task_queues
.
task_default_exchange_type
¶
По умолчанию: "direct"
.
Тип обмена по умолчанию, используемый, когда для ключа не указан пользовательский тип обмена в настройке task_queues
.
task_default_routing_key
¶
По умолчанию: Используется значение, установленное для task_default_queue
.
Ключ маршрутизации по умолчанию, используемый, если для ключа не указан пользовательский ключ маршрутизации в настройке task_queues
.
task_default_delivery_mode
¶
По умолчанию: "persistent"
.
Может быть переходным (сообщения не записываются на диск) или постоянным (записываются на диск).
Настройки брокера¶
broker_url
¶
По умолчанию: "amqp://"
URL брокера по умолчанию. Это должен быть URL в форме:
transport://userid:password@hostname:port/virtual_host
Только часть схемы (transport://
) является обязательной, остальное необязательно, и по умолчанию имеет значения по умолчанию для конкретного транспорта.
Транспортная часть - это используемая реализация брокера, по умолчанию amqp
, (используется librabbitmq
, если установлен, или возвращается к pyamqp
). Есть и другие варианты, включая redis://
, sqs://
и qpid://
.
Схема также может быть полностью определенным путем к вашей собственной реализации транспорта:
broker_url = 'proj.transports.MyTransport://localhost'
Также можно указать более одного URL брокера одного и того же транспорта. URL брокера можно передать в виде одной строки, разделенной точкой с запятой:
broker_url = 'transport://userid:password@hostname:port//;transport://userid:password@hostname:port//'
Или в виде списка:
broker_url = [
'transport://userid:password@localhost:port//',
'transport://userid:password@hostname:port//'
]
Затем брокеры будут использоваться в broker_failover_strategy
.
Более подробную информацию смотрите в kombu:connection-urls в документации Kombu.
broker_read_url
/ broker_write_url
¶
По умолчанию: Взято из broker_url
.
Эти параметры можно настроить вместо broker_url
, чтобы указать различные параметры соединения для брокерских соединений, используемых для потребления и производства.
Пример:
broker_read_url = 'amqp://user:pass@broker.example.com:56721'
broker_write_url = 'amqp://user:pass@broker.example.com:56722'
Оба параметра также могут быть указаны в виде списка для альтернативных вариантов обхода отказа, более подробную информацию см. в broker_url
.
broker_failover_strategy
¶
По умолчанию: "round-robin"
.
Стратегия обхода отказа по умолчанию для объекта Connection брокера. Если задано, может соответствовать ключу в „kombu.connection.failover_strategies“, или быть ссылкой на любой метод, который выдает один элемент из заданного списка.
Пример:
# Random failover strategy
def random_failover_strategy(servers):
it = list(servers) # don't modify callers list
shuffle = random.shuffle
for _ in repeat(None):
shuffle(it)
yield it[0]
broker_failover_strategy = random_failover_strategy
broker_heartbeat
¶
- поддерживаемые транспорты:
pyamqp
По умолчанию: 120.0
(согласовывается сервером).
Примечание: Это значение используется только работником, клиенты в настоящее время не используют сердцебиение.
Не всегда возможно своевременно обнаружить потерю соединения, используя только TCP/IP, поэтому AMQP определяет нечто под названием heartbeats, которое используется как клиентом, так и брокером для определения того, было ли закрыто соединение.
Если значение пульса равно 10 секундам, то пульс будет отслеживаться с интервалом, заданным параметром broker_heartbeat_checkrate
(по умолчанию он установлен в два раза больше значения пульса, поэтому для 10 секунд пульс проверяется каждые 5 секунд).
broker_heartbeat_checkrate
¶
- поддерживаемые транспорты:
pyamqp
По умолчанию: 2.0.
Через определенные промежутки времени рабочий будет проверять, не пропустил ли брокер слишком много ударов сердца. Скорость проверки рассчитывается путем деления значения broker_heartbeat
на это значение, поэтому если пульс равен 10.0, а скорость по умолчанию 2.0, то проверка будет выполняться каждые 5 секунд (удвоенная скорость отправки пульса).
broker_use_ssl
¶
- поддерживаемые транспорты:
pyamqp
,redis
По умолчанию: Отключено.
Переключает использование SSL на брокерском соединении и настройках SSL.
Допустимые значения для этого параметра зависят от транспорта.
pyamqp
¶
Если True
, соединение будет использовать SSL с настройками SSL по умолчанию. Если задано dict, будет настроено SSL-соединение в соответствии с указанной политикой. Используется формат опций Python ssl.wrap_socket()
.
Обратите внимание, что SSL-сокет обычно обслуживается брокером на отдельном порту.
Пример предоставления клиентского сертификата и проверки сертификата сервера в пользовательском центре сертификации:
import ssl
broker_use_ssl = {
'keyfile': '/var/ssl/private/worker-key.pem',
'certfile': '/var/ssl/amqp-server-cert.pem',
'ca_certs': '/var/ssl/myca.pem',
'cert_reqs': ssl.CERT_REQUIRED
}
Предупреждение
Будьте осторожны, используя broker_use_ssl=True
. Возможно, что ваша конфигурация по умолчанию вообще не будет проверять сертификат сервера. Пожалуйста, прочитайте Python ssl module security considerations.
redis
¶
Настройка должна быть диктуется следующими клавишами:
ssl_cert_reqs
(требуется): одно из значенийSSLContext.verify_mode
:ssl.CERT_NONE
ssl.CERT_OPTIONAL
ssl.CERT_REQUIRED
ssl_ca_certs
(необязательно): путь к сертификату ЦСssl_certfile
(необязательно): путь к клиентскому сертификатуssl_keyfile
(необязательно): путь к клиентскому ключу
broker_pool_limit
¶
Добавлено в версии 2.3.
По умолчанию: 10.
Максимальное количество соединений, которые могут быть открыты в пуле соединений.
Пул включен по умолчанию, начиная с версии 2.5, с ограничением по умолчанию в десять соединений. Это число может быть изменено в зависимости от количества потоков/гринлетов (eventlet/gevent), использующих соединение. Например, при запуске eventlet с 1000 greenlet, которые используют соединение с брокером, может возникнуть конкуренция, и вам следует рассмотреть возможность увеличения лимита.
Если установлено значение None
или 0, пул соединений будет отключен, а соединения будут устанавливаться и закрываться при каждом использовании.
broker_connection_timeout
¶
По умолчанию: 4.0.
Таймаут по умолчанию в секундах до отказа от установления соединения с сервером AMQP. Эта настройка отключена при использовании gevent.
Примечание
Таймаут соединения с брокером применяется только к рабочему, пытающемуся подключиться к брокеру. Он не применяется к производителю, отправляющему задание, см. broker_transport_options
о том, как обеспечить тайм-аут для этой ситуации.
broker_connection_retry
¶
По умолчанию: Включено.
Автоматически пытаться восстановить соединение с брокером AMQP в случае его потери.
Время между повторными попытками увеличивается для каждой повторной попытки и не исчерпывается до превышения broker_connection_max_retries
.
broker_connection_max_retries
¶
По умолчанию: 100.
Максимальное количество повторных попыток, прежде чем мы откажемся от повторного установления соединения с брокером AMQP.
Если это значение равно 0
или None
, мы будем повторять попытку до бесконечности.
broker_login_method
¶
По умолчанию: "AMQPLAIN"
.
Установите пользовательский метод входа amqp.
broker_transport_options
¶
Добавлено в версии 2.2.
По умолчанию: {}
(пустое отображение).
Набор дополнительных опций, передаваемых базовому транспорту.
Поддерживаемые опции (если таковые имеются) см. в руководстве пользователя вашего транспорта.
Пример установки таймаута видимости (поддерживается транспортами Redis и SQS):
broker_transport_options = {'visibility_timeout': 18000} # 5 hours
Пример установки максимального числа повторных попыток соединения с производителем (чтобы производители не повторяли попыток до бесконечности, если брокер недоступен при первом выполнении задания):
broker_transport_options = {'max_retries': 5}
Рабочий¶
imports
¶
По умолчанию: []
(пустой список).
Последовательность модулей для импорта при запуске рабочего.
Используется для указания модулей задач для импорта, а также для импорта обработчиков сигналов, дополнительных команд дистанционного управления и т.д.
Модули будут импортированы в исходном порядке.
include
¶
По умолчанию: []
(пустой список).
Точно такая же семантика, как и imports
, но может использоваться как средство для различных категорий импорта.
Модули в этой настройке импортируются после модулей в imports
.
worker_deduplicate_successful_tasks
¶
Добавлено в версии 5.1.
По умолчанию: Ложь
Перед выполнением каждой задачи поручите работнику проверить, не является ли эта задача дублирующим сообщением.
Дедупликация происходит только с заданиями, которые имеют одинаковый идентификатор, включено позднее подтверждение, были повторно доставлены брокером сообщений и их состояние SUCCESS
в бэкенде результатов.
Чтобы избежать переполнения бэкенда результатов запросами, перед запросом к бэкенду результатов проверяется локальный кэш успешно выполненных заданий на случай, если задание уже было успешно выполнено тем же рабочим, который получил задание.
Этот кэш можно сделать постоянным, установив параметр worker_state_db
.
Если бэкенд результата не является постоянным (например, бэкенд RPC), этот параметр игнорируется.
worker_concurrency
¶
По умолчанию: Количество ядер процессора.
Количество параллельных рабочих процессов/потоков/зеленых потоков, выполняющих задания.
Если вы выполняете в основном операции ввода-вывода, вы можете иметь больше процессов, но если вы в основном заняты процессором, старайтесь, чтобы это число было близко к числу процессоров на вашей машине. Если значение не установлено, будет использоваться количество CPU/ядер на хосте.
worker_prefetch_multiplier
¶
По умолчанию: 4.
Количество сообщений для предварительной выборки за один раз, умноженное на количество параллельных процессов. По умолчанию - 4 (четыре сообщения для каждого процесса). Однако значение по умолчанию обычно является хорошим выбором - если у вас есть очень долго выполняющиеся задачи, ожидающие своей очереди, и вы должны запустить рабочих, обратите внимание, что первый запущенный рабочий получит в четыре раза больше сообщений, чем первоначально. Таким образом, задания могут быть распределены между рабочими несправедливо.
Чтобы отключить предварительную выборку, установите worker_prefetch_multiplier
в 1. Изменение этого параметра на 0 позволит рабочему продолжать потреблять столько сообщений, сколько он хочет.
Для получения дополнительной информации о префетчинге читайте Пределы предварительной выборки.
Примечание
На задачи с ETA/countdown не влияют ограничения на предварительную выборку.
worker_lost_wait
¶
По умолчанию: 10,0 секунд.
В некоторых случаях рабочий может быть завершен без надлежащей очистки, и рабочий может опубликовать результат до завершения работы. Это значение определяет, как долго мы будем ждать отсутствующих результатов, прежде чем поднять исключение WorkerLostError
.
worker_max_tasks_per_child
¶
Максимальное количество задач, которые может выполнить рабочий процесс пула, прежде чем он будет заменен новым. По умолчанию - без ограничения.
worker_max_memory_per_child
¶
По умолчанию: Без ограничения. Тип: int (килобайты)
Максимальный объем резидентной памяти, в килобайтах, который может быть израсходован рабочим, прежде чем он будет заменен новым рабочим. Если в результате выполнения одной задачи рабочий превысит этот предел, задача будет завершена, а рабочий будет заменен после этого.
Пример:
worker_max_memory_per_child = 12000 # 12MB
worker_disable_rate_limits
¶
По умолчанию: Выключено (ограничения скорости включены).
Отключить все ограничения скорости, даже если для задач установлены явные ограничения скорости.
worker_state_db
¶
По умолчанию: None
.
Имя файла, используемого для хранения постоянного состояния рабочих (например, отозванных заданий). Это может быть относительный или абсолютный путь, но имейте в виду, что к имени файла может быть добавлен суффикс .db (в зависимости от версии Python).
Также может быть задан через аргумент celery worker --statedb
.
worker_timer_precision
¶
По умолчанию: 1,0 секунды.
Установите максимальное время в секундах, в течение которого планировщик ETA может спать между перепроверками расписания.
Установка этого значения в 1 секунду означает, что точность планировщика будет равна 1 секунде. Если вам нужна точность, близкая к миллисекунде, вы можете установить значение 0,1.
worker_enable_remote_control
¶
По умолчанию: Включено по умолчанию.
Укажите, разрешено ли удаленное управление рабочими.
worker_proc_alive_timeout
¶
По умолчанию: 4.0.
Тайм-аут в секундах (int/float) при ожидании запуска нового рабочего процесса.
worker_cancel_long_running_tasks_on_connection_loss
¶
Добавлено в версии 5.1.
По умолчанию: По умолчанию отключено.
Убивать все длительно выполняющиеся задачи с включенным поздним подтверждением при потере соединения.
Задачи, которые не были подтверждены до потери связи, больше не могут этого сделать, так как их канал пропадает, и задача возвращается обратно в очередь. Именно поэтому задачи с включенным поздним подтверждением должны быть идемпотентными, так как они могут выполняться более одного раза. В данном случае задание выполняется дважды при потере соединения (и иногда параллельно в других рабочих).
При включении этой опции те задачи, которые не были завершены, отменяются и их выполнение прекращается. Задачи, которые каким-либо образом завершились до потери соединения, записываются как таковые в бэкенд результатов, если не включена опция task_ignore_result
.
Предупреждение
Эта функция была введена в качестве будущего изменения. Если она будет отключена, Celery выдаст предупреждающее сообщение.
В Celery 6.0 значение worker_cancel_long_running_tasks_on_connection_loss
по умолчанию будет установлено на True
, так как текущее поведение приводит к большему количеству проблем, чем решает.
События¶
worker_send_task_events
¶
По умолчанию: По умолчанию отключено.
Посылает события, связанные с задачами, чтобы их можно было отслеживать с помощью таких инструментов, как flower. Устанавливает значение по умолчанию для аргумента workers -E
.
task_send_sent_event
¶
Добавлено в версии 2.2.
По умолчанию: По умолчанию отключено.
Если включено, для каждой задачи будет отправляться событие task-sent
, чтобы задачи можно было отследить до того, как они будут потреблены рабочим.
event_queue_ttl
¶
- поддерживаемые транспорты:
amqp
По умолчанию: 5,0 секунд.
Время истечения срока действия сообщения в секундах (int/float), когда сообщения, отправленные в очередь событий клиентов монитора, удаляются (x-message-ttl
).
Например, если это значение установлено в 10, то сообщение, доставленное в эту очередь, будет удалено через 10 секунд.
event_queue_expires
¶
- поддерживаемые транспорты:
amqp
По умолчанию: 60,0 секунд.
Время истечения в секундах (int/float), по истечении которого очередь событий клиентов монитора будет удалена (x-expires
).
event_queue_prefix
¶
По умолчанию: "celeryev"
.
Префикс, используемый для имен очередей приемников событий.
event_exchange
¶
По умолчанию: "celeryev"
.
Название биржи событий.
Предупреждение
Эта опция находится на экспериментальной стадии, пожалуйста, используйте ее с осторожностью.
event_serializer
¶
По умолчанию: "json"
.
Формат сериализации сообщений, используемый при отправке сообщений о событиях.
См.также
Команды дистанционного управления¶
Примечание
Для отключения команд дистанционного управления см. настройку worker_enable_remote_control
.
control_queue_ttl
¶
По умолчанию: 300.0
Время в секундах до истечения срока действия сообщения в очереди команд дистанционного управления.
Если используется значение по умолчанию 300 секунд, это означает, что если отправлена команда удаленного управления и ни один работник не принимает ее в течение 300 секунд, команда отбрасывается.
Эта настройка также применяется к очередям ответов дистанционного управления.
control_queue_expires
¶
По умолчанию: 10.0
Время в секундах, прежде чем неиспользуемая очередь команд дистанционного управления будет удалена из брокера.
Эта настройка также применяется к очередям ответов дистанционного управления.
control_exchange
¶
По умолчанию: "celery"
.
Название обмена управляющими командами.
Предупреждение
Эта опция находится на экспериментальной стадии, пожалуйста, используйте ее с осторожностью.
Ведение журнала¶
worker_hijack_root_logger
¶
Добавлено в версии 2.2.
По умолчанию: Включено по умолчанию (перехват корневого регистратора).
По умолчанию все ранее настроенные обработчики на корневом логгере будут удалены. Если вы хотите настроить свои собственные обработчики логов, то вы можете отключить это поведение, установив worker_hijack_root_logger = False.
Примечание
Ведение журнала также может быть настроено путем подключения к сигналу celery.signals.setup_logging
.
worker_log_color
¶
По умолчанию: Включено, если приложение регистрируется на терминале.
Включает/выключает цвета в логах, выводимых приложениями Celery.
worker_log_format
¶
По умолчанию:
"[%(asctime)s: %(levelname)s/%(processName)s] %(message)s"
Формат, используемый для сообщений журнала.
Дополнительную информацию о форматах журналов см. в модуле Python logging
.
worker_task_log_format
¶
По умолчанию:
"[%(asctime)s: %(levelname)s/%(processName)s]
[%(task_name)s(%(task_id)s)] %(message)s"
Формат, используемый для сообщений журнала, регистрируемых в задачах.
Дополнительную информацию о форматах журналов см. в модуле Python logging
.
worker_redirect_stdouts
¶
По умолчанию: Включено по умолчанию.
Если включено, stdout и stderr будут перенаправлены в текущий логгер.
Используется celery worker и celery beat.
worker_redirect_stdouts_level
¶
По умолчанию: WARNING
.
Уровень журнала, выводимый в stdout и stderr. Может быть одним из DEBUG
, INFO
, WARNING
, ERROR
или CRITICAL
.
Безопасность¶
security_key
¶
По умолчанию: None
.
Добавлено в версии 2.5.
Относительный или абсолютный путь к файлу, содержащему закрытый ключ, используемый для подписи сообщений при использовании Подписание сообщений.
security_certificate
¶
По умолчанию: None
.
Добавлено в версии 2.5.
Относительный или абсолютный путь к файлу сертификата X.509, используемого для подписи сообщений при использовании Подписание сообщений.
security_cert_store
¶
По умолчанию: None
.
Добавлено в версии 2.5.
Каталог, содержащий сертификаты X.509, используемые для Подписание сообщений. Может представлять собой глобальную структуру с символами подстановки (например, /etc/certs/*.pem
).
security_digest
¶
По умолчанию: sha256
.
Добавлено в версии 4.3.
Криптографический дайджест, используемый для подписи сообщений, когда используется Подписание сообщений. https://cryptography.io/en/latest/hazmat/primitives/cryptographic-hashes/#module-cryptography.hazmat.primitives.hashes
Классы пользовательских компонентов (расширенный)¶
worker_pool
¶
По умолчанию: "prefork"
(celery.concurrency.prefork:TaskPool
).
Имя класса пула, используемого рабочим.
Eventlet/Gevent
Никогда не используйте эту опцию для выбора пула eventlet или gevent. Вы должны использовать опцию -P
вместо celery worker, чтобы гарантировать, что исправления обезьяны не будут применены слишком поздно, что приведет к странным поломкам.
worker_pool_restarts
¶
По умолчанию: По умолчанию отключено.
Если включено, рабочий пул может быть перезапущен с помощью команды удаленного управления pool_restart
.
worker_autoscaler
¶
Добавлено в версии 2.2.
По умолчанию: "celery.worker.autoscale:Autoscaler"
.
Имя класса автоскалера, который будет использоваться.
worker_consumer
¶
По умолчанию: "celery.worker.consumer:Consumer"
.
Имя класса потребителя, используемого работником.
worker_timer
¶
По умолчанию: "kombu.asynchronous.hub.timer:Timer"
.
Имя класса планировщика ETA, используемого рабочим. По умолчанию или задается реализацией пула.
Настройки ударов (celery beat)¶
beat_schedule
¶
По умолчанию: {}
(пустое отображение).
Периодическое расписание задач, используемое beat
. См. Записи.
beat_scheduler
¶
По умолчанию: "celery.beat:PersistentScheduler"
.
Класс планировщика по умолчанию. Может быть установлен, например, в "django_celery_beat.schedulers:DatabaseScheduler"
, если используется вместе с расширением django-celery-beat.
Также может быть задан через аргумент celery beat -S
.
beat_schedule_filename
¶
По умолчанию: "celerybeat-schedule"
.
Имя файла, используемого PersistentScheduler для хранения времени последнего запуска периодических задач. Это может быть относительный или абсолютный путь, но имейте в виду, что к имени файла может быть добавлен суффикс .db (в зависимости от версии Python).
Также может быть задан через аргумент celery beat --schedule
.
beat_sync_every
¶
По умолчанию: 0.
Количество периодических задач, которые могут быть вызваны до того, как будет произведена очередная синхронизация базы данных. Значение 0 (по умолчанию) означает синхронизацию по времени - по умолчанию 3 минуты, определяемые scheduler.sync_every. Если установить значение 1, то beat будет вызывать синхронизацию после каждого отправленного сообщения задачи.
beat_max_loop_interval
¶
По умолчанию: 0.
Максимальное количество секунд beat
может спать между проверкой расписания.
Значение по умолчанию для этого параметра зависит от планировщика. Для планировщика Celery beat по умолчанию значение равно 300 (5 минут), но для планировщика базы данных django-celery-beat это 5 секунд, потому что расписание может быть изменено извне, и поэтому оно должно учитывать изменения в расписании.
Также при запуске Celery beat embedded (-B
) на Jython в качестве потока максимальный интервал переопределяется и устанавливается равным 1, чтобы можно было своевременно завершить работу.