Использование Redis

Установка

Для поддержки Redis необходимо установить дополнительные зависимости. Вы можете установить Celery и эти зависимости одним махом, используя celery[redis] bundle:

$ pip install -U "celery[redis]"

Конфигурация

Настройка проста, достаточно указать местоположение базы данных Redis:

app.conf.broker_url = 'redis://localhost:6379/0'

Где URL имеет формат:

redis://:password@hostname:port/db_number

все поля после схемы являются необязательными, и по умолчанию будут использоваться localhost на порту 6379, используя базу данных 0.

Если должно использоваться сокетное соединение Unix, URL должен быть в формате:

redis+socket:///path/to/redis.sock

Указание другого номера базы данных при использовании сокета Unix возможно путем добавления параметра virtual_host в URL:

redis+socket:///path/to/redis.sock?virtual_host=db_number

Также легко подключиться непосредственно к списку Redis Sentinel:

app.conf.broker_url = 'sentinel://localhost:26379;sentinel://localhost:26380;sentinel://localhost:26381'
app.conf.broker_transport_options = { 'master_name': "cluster1" }

Дополнительные опции могут быть переданы клиенту Sentinel с помощью sentinel_kwargs:

app.conf.broker_transport_options = { 'sentinel_kwargs': { 'password': "password" } }

Таймаут видимости

Таймаут видимости определяет количество секунд, в течение которых нужно ждать, пока рабочий подтвердит задание, прежде чем сообщение будет повторно передано другому рабочему. Обязательно посмотрите Оговорки ниже.

Этот параметр устанавливается с помощью настройки broker_transport_options:

app.conf.broker_transport_options = {'visibility_timeout': 3600}  # 1 hour.

Таймаут видимости по умолчанию для Redis составляет 1 час.

Результаты

Если вы также хотите хранить состояние и возвращаемые значения задач в Redis, вам следует настроить следующие параметры:

app.conf.result_backend = 'redis://localhost:6379/0'

Полный список опций, поддерживаемых бэкендом результатов Redis, приведен в разделе Настройки бэкенда Redis.

Если вы используете Sentinel, вам следует указать имя master_name с помощью параметра result_backend_transport_options:

app.conf.result_backend_transport_options = {'master_name': "mymaster"}

Таймауты соединения

Чтобы настроить таймауты соединения для бэкенда результатов Redis, используйте ключ retry_policy под result_backend_transport_options:

app.conf.result_backend_transport_options = {
    'retry_policy': {
       'timeout': 5.0
    }
}

Возможные варианты политики повторных попыток см. в retry_over_time().

Оговорки

Тайм-аут видимости

Если задание не было подтверждено в течение Таймаут видимости, оно будет повторно передано другому работнику и выполнено.

Это вызывает проблемы с задачами ETA/countdown/retry, где время выполнения превышает таймаут видимости; фактически, если это произойдет, задача будет выполняться снова и снова в цикле.

Поэтому вы должны увеличить таймаут видимости, чтобы он соответствовал времени самого длинного ETA, которое вы планируете использовать.

Обратите внимание, что Celery будет повторно доставлять сообщения при отключении рабочих, поэтому длительный тайм-аут видимости только задержит повторную доставку «потерянных» заданий в случае сбоя питания или принудительного отключения рабочих.

Периодические задачи не будут затронуты тайм-аутом видимости, поскольку это концепция, отдельная от ETA/countdown.

Вы можете увеличить этот тайм-аут, настроив транспортный параметр с тем же именем:

app.conf.broker_transport_options = {'visibility_timeout': 43200}

Значение должно представлять собой число int, описывающее количество секунд.

Выселение ключей

Redis может извлекать ключи из базы данных в некоторых ситуациях

Если у вас возникла ошибка типа:

InconsistencyError: Probably the key ('_kombu.binding.celery') has been
removed from the Redis database.

тогда вы можете настроить redis-server на то, чтобы не выселять ключи, задав это в конфигурационном файле redis:

  • опция maxmemory

  • опцию maxmemory-policy на noeviction или << 2 >>>

Подробнее см. документацию сервера Redis о политиках выселения:

Упорядочение групповых результатов

Версии Celery до версии 4.4.6 включительно использовали несортированный список для хранения объектов результатов для групп в бэкенде Redis. Это может привести к тому, что результаты будут возвращены в другом порядке, чем связанные с ними задачи в исходной инстанциации группы. В Celery 4.4.7 было введено опциональное поведение, которое устраняет эту проблему и гарантирует, что результаты групп возвращаются в том же порядке, в котором были определены задачи, что соответствует поведению других бэкендов. В Celery 5.0 это поведение было изменено на opt-out. Поведение контролируется параметром конфигурации result_chord_ordered, который может быть установлен следующим образом:

# Specifying this for workers running Celery 4.4.6 or earlier has no effect
app.conf.result_backend_transport_options = {
    'result_chord_ordered': True    # or False
}

Это несовместимое изменение в поведении рабочих, использующих один и тот же бэкенд Redis для хранения результатов, поэтому все рабочие должны следовать либо новому, либо старому поведению, чтобы избежать поломки. Для кластеров с некоторыми рабочими под управлением Celery 4.4.6 или более ранних версий это означает, что рабочие под управлением 4.4.7 не нуждаются в специальной конфигурации, а рабочие под управлением 5.0 или более поздних версий должны иметь result_chord_ordered, установленный в False. Для кластеров, в которых нет рабочих под управлением 4.4.6 или более ранних версий, но есть рабочие под управлением 4.4.7, рекомендуется установить result_chord_ordered на True для всех рабочих, чтобы облегчить будущую миграцию. Миграция между моделями поведения нарушит результаты, хранящиеся в бэкенде Redis, и приведет к сбоям, если последующие задачи будут выполняться мигрировавшими рабочими - планируйте соответствующим образом.

Использование RabbitMQ
Использование Amazon SQS
Вернуться на верх