СОЗДАЕМ СВОЙ CELERY ЧЕРЕЗ REDIS. BACKGROUND WORKERS В ПИТОНЕ

У меня недавно была задача в Cylery решена.
бек на FastApi
1-Загружалась картинка. после загрузки, она обрабатывалась и сохранялась на S3. Запись в бд и т.п.
2-Дальше, скачивалась, делались преобразования, всякие записи в БД, аплоад на S3.
Без Celery, приходилось долго ждать ответа.
Теперь, ответ сразу после 1п. Затем формируется задача для воркера по 2п.
Удобно.
Надо еще почту повесить на воркер.

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

Круто!

рама два вандама

Кул

В восторге от канала))) Спасибо за труд!

звук)))

Интересно, спасибо

А почему не использовать "взрослую" систему управления очередями типа rabbitMQ ?

Спасибо за труд , Андрей !
У меня вопрос , в каких случаях может возникать такая ошибка - WRONGTYPE Operation against a key holding the wrong kind of value.

Если правильно понимаю, то все-таки от запуска двух процессов на одной машине есть некая польза-если нужно рассинхронизировать два процесса как раз с помощью redis.

В целом классно, но картинка сначала ужас - сумерки как в 240p..

Почему профита от запуска на одной машине не будет? Как минимум это разделение логики и параллельная работа. Хоть программы и будут использовать одни и те же ресурсы, однако их работа будет независима друг от друга. Если есть баг, или просто разная нагрузка/функционал, то если один сервис упадет, то второй продолжит работать. Например, у нас есть сервис, который отвечает за прием документов, обработку их, и отправку результатов. Документы нам приходят в воркер, который запускает обработку документов. На основной сервис, допустим, к нам приходит результат от внутренней системы, output воркер занимается тем, что пытается отправить результат клиенту. Если у нас отвалится прием документов, то мы не хотим, что бы два других компонента перестали работать . Поэтому стоит разделить на сервис с апи и два отдельных воркера, вне зависимости, будут они запущены на одном устройстве или на разных.

Хорошо бы пример довести до логического конца.
Пока бэк не работает - примеры (problem) формируют очередь (list), как только бэк включился - прорешались вывелись все накопленные (problem`s)

Огромное спасибо за ваши уроки!

Все круто, но данная реализация не решает проблему о которой было заявлено, так как background_worker блокируют основной поток и, по факту, это равносильно тому, если в main объявить функцию, которая будет так же через eval что-то вычислять. + такой реализации в том, что можно вычислять на другой тачке, но на мой взгляд, это не оправдано. Точно так же будешь ждать пол часа, пока сформируется отчет, о котором говорилось в начале видео. Короче, надо допилить до ума эту реализацию, не ждать ответ от background_worker'a а слушать евент от редиса об окончании вычисления и возвращать результат конечному пользователю, тогда будет топ.

Отличное видео! Все понятно

сук шо.с дикцией) пеРРВОЭЕ ВТОРРОЭЕ аззузаз

Плохой пример. Отправляем задачу и ждем решение и новую не добавить. А если решение 30 минут занимает - мы и будем ждать 30 минут, нельзя сразу 5 например решений отправить.