Использование Redis в качестве обработчика результатов Celery и брокера сообщений - срок действия задачи (для ключа, хранящегося в redis) - PullRequest
0 голосов
/ 13 декабря 2018

Я использую Celery, Redis как message broker и result backend.Мне неясно, что означает истечение срока действия задания или истечение срока действия ключа в Redis.

Просто чтобы было ясно, когда клиент Celery запускает задание, он генерирует уникальный идентификатор_программы "celery-task-meta-64h4378-875ug43-6523g" this is what it stores in Redis as a KEY (Just example) для каждой задачи и помещает его в очередь сообщений.Затем работники сельдерея проверят очередь сообщений и выполнят задачи в зависимости от количества рабочих.Если работник выполнил задание и пометил задание как УСПЕХ / ОТКАЗ, он не изменит его на ОЖИДАНИЕ или любое другое состояние.

Документы Celery говорят, чтовремя истечения соответствует времени после «публикации» задачи, но я не смог найти никакой информации о том, что на самом деле означает «публикация».

Я знаю, что сельдерей хранит задачу как ключ Redis и имеет срок действия по умолчанию1 day (86400 seconds).В моем случае один раз после того, как задача создана и сохранена в Redis как KEY, работнику требуется больше времени для выполнения задачи и обновления результата для этой задачи, независимо от того, является ли это успехом / неудачей.

Вопрос № 1: Относительно времени истечения срока действия ключа Redis. Это 1 день по умолчанию, который создает сельдерей, учитывается сразу с момента создания ключа или после обновления результата задачи на ключпо работнику (I mean key created in Redis -> worker started that task -> worker finished and updated the task (Key in redis)) ..?

Меня беспокоит только то, что после того, как сельдерей создал новое задание, работник затем приступил к выполнению этого задания, и на его выполнение уходит более одного дня (наихудший случай).Если у нас будет все больше и больше созданных задач) и в то же время, если срок действия ключа KEY истечет в Redis ... , что делать в этих случаях ..?

Быстрыйрешение состоит в том, чтобы увеличить срок действия ключа Redis более чем на один день:)

Вопрос № 2: Является ли переход на RabbitMq вместо Redis в приведенном выше сценарии хорошим выбором?В этом случае мы можем сохранить результат в постоянной базе данных, и нам не нужно беспокоиться о времени истечения срока действия, а также о случаях заполнения кэша Redis In-Memory.

Пожалуйста, исправьте меня, если я беспокоюсь опонимать что-то в вышеупомянутых пунктах.Любая обратная связь / помощь по этому вопросу будет принята с благодарностью:)

1 Ответ

0 голосов
/ 15 декабря 2018

Вопрос № 1: Время истечения, на которое вы ссылаетесь в ссылке, начинается с момента совершения вызова apply_async или delay.

Вопрос № 2: Любой из них является хорошимвыбор.Redis немного менее надежен, но намного проще в настройке, чем rabbitmq.Тем не менее, использование rabbitmq в качестве вашего брокера - безусловно, самый популярный выбор, который делает большинство разработчиков.YMMV.

...