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

СОЗДАЕМ СВОЙ CELERY ЧЕРЕЗ REDIS. BACKGROUND WORKERS В ПИТОНЕ
Python on Papyrus RU.
Мои курсы на UDEMY: www.udemy.com/...
Пожертвования: www.donational...
Github: github.com/knu...
Telegram канал: t.me/pypapyrus_ru
Другие Видео по Python: • Python, Питон
Канал на английском языке: / @pythononpapyrus
Поставьте лайк и подпишитесь!
#Python #Питон #программирование #programming

[@ЕвгенийДмитриевич-х6г]

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

[@isded1681]

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

[@JohnKannedy]

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

[@ZVA_NOOK]

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

[@exe88cution]

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

[@oreshkinalexey]

Круто!

[@igorlarrson955]

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

[@user-fc1et1lz4r]

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

[@kanareikaTv]

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

[@АльКапоне-щ5й]

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

[@jetbrain9115]

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

[@AlexandrSpirit]

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

[@PythononPapyrusRU]

Послезавтра сделаю видео про сбор логов через ELK

[@imbaquad]

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

[@ruslanways]

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

[@ALekraf]

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

[@glow_pick]

звук)))

[@ИгорьЛатуха]

Кул

[@Bunkerniy_Gadenish]

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