Комментарии 13
Хорошая замена Celery
На самом деле не очень. Посмотрите в сторону https://taskiq-python.github.io/
Смотрел, но как было сказано в статье для меня было важным критерием 500+ звёзд. Версия библиотеки 0.5, но на главной странице заявлено что она production ready. Что тоже вызвало некоторые сомнения. Хочу и могу назвать библиотеку сырой, хотя выглядит она вполне себе неплохо. Возможно позже она заменит всех вышеперечисленных, но пока что я предпочту подождать
для меня было важным критерием 500+ звёзд
Вы так говорите, словно миллионы мух не могут ошибаться </шутка>. Звёзды значат только популярность, и ничего более. "Сырость" версии библиотеки также мало что значит -- надо в сорцы смотреть
Причём, включая популярность вида "узнал о библиотеке, нагуглил и поставил звезду, чтобы не забыть и когда-нибудь пощупать". Для многих раздел stars в профиле GitHub -- это просто раздел закладок.
Больше смысла в оценке проекта может иметь количество контрибьютеров и характер их коммитов. Если в кодовую базу проекта глубоко погружены два открытых к диалогу человека -- это может быть лучше раскрученного проекта одиночки, пропадающего на полгода или переводящего все неинтересные ему Issues в Disscussions.
Я понимаю что версионность каждый ведёт как хочет. Но у меня был неприятный опыт использования подобной библиотеки. Дважды наступать на грабли я не хочу. Такие библиотеки (непопулярные) генерируют намного меньше issues оттого багов в ней может быть потенциально больше. Не поймите меня не правильно, но писать на главной странице что мы готовы в продакшену когда проект только-только появляется это тоже перебор. Я хочу чтобы библиотека жила и развивалась. Я чуть было не взял AMQ, который тут тоже любят рекомендовать. Только вот уже более полугода без релизов. И да, останусь при своём, звёзды в большинстве случаев отражают приблизительную реальность. И если бы я смотрел только на звёзды - тогда бы я остался использовать Celery, ведь там их в 20 раз больше, не так ли?)
а между прочим, проект преодолел установленную вами виртуальную планку, может пришло время попробовать?
Время пришло
Выглядит интересно, спасибо. А для замены flower есть что или придётся городить что-то своё?
Кстати, интересный вопрос. Я, было, хотел вам ответить что придется свое, но решил погуглить.
Есть, вроде бы, проект open-telemetry, у которого есть раздел "OpenTelemetry Aio-pika Instrumentation" на гитхабе. Также есть неких helios, который тоже что-то может делать с aio-pika. Я лично ни с чем из них дела не имел и ничего не могу сказать, но вот есть.
UPD: заметил что вы спрашивали про taskiq, сорри. С ним тоже не работал, но у него заявлена поддержка Prometheus для сбора метрик.
Да, звезды на гитхабе мало что показывают.
aio-pika - это развитие проекта pika, который, пожалуй, даже будет постарше amqplib (используется в kombu/celery). В древние времена pika уже была, но предоставляла слишком уж низкоуровневый интерфейс и kombu выглядел гораздо удобнее, особенно позволяя использовать разные брокеры (RabbitMQ, Redis, Postgresql, ...).
В статье все-таки вы некорректно сравниваете celery с aio-pika. Это немного разные уровни. Celery - это полноценный фреймворк, который позволяет кучу разных вещей, управляя воркерами-процессами, конфигурируя очереди и сообщения. Он базируется на kombu, который берет на себя оркестрацию разными протоколами, предоставляя одинаковую абстракцию над ними - организует очереди одинаковым образом в разных брокерах.
aio-pika можно ограниченно сравнивать с kombu при работе только с AMQP. Возможно, кстати, вам бы лучше подошел механизм RPC в ней. Однако, по сравнению с celery вам придется писать гораздо больше своего кода для контроля выполнения - воркер может тихо помереть,потерять задачу, она может уйти по таймауту, результат может не записаться и тп. celery все это берет на себя. Однако, он, конечно, уже устарел и оброс кучей тяжелого кода.
Кстати, разделение кода для celery - это вполне реально. Разный код, с разными тасками, но подсоединяясь к одной очереди вы можете вызывать любую таску, передав ее имя в сообщении.
С разделением кода для celery звучит конечно не очень) пожалуй напишу больше кода для aio-pika
На счёт сравнения с Celery. Во первых, если прочитать статью что заголовок означает то, что я выкинул из проекта Celery заменив на aio-pika и стало лучше. Во вторых это отчасти уместно сравнивать т.к. в большинстве мест где используется Celery можно было бы обойтись именно такими быстрыми и лёгкими вариантами вокруг AMPQ. Celery старый и надёжный ящик. О котором все знают и берут его для работы с очередями и для отложенных задач. Цель статьи - распространять далее идею о том что celery это не единственное что можно для этого взять.
На счёт RPC, да, к сожалению обратил на него внимание слишком поздно. Можно было бы и через него. Но в целом даже смотря сейчас на свой результат, мне он понравился, и не так много кода я написал, чтобы этого достичь.
Да все в порядке, не воспринимайте мой комментарий как критику - скорее просто как дополнение. Статья, в целом, правильная и первый плюс за нее был мой.
Я и сам, в последнее время, все чаще использую разные сервисы на aio-pika и все реже celery. Однако, кстати, есть класс задач, в котором асинхронные воркеры не дадут особого выигрыша - это разные ML-задачи и вообще CPU-тяжелые обсчеты. Делить процессор они никому не дадут и здесь celery с их управлением воркерами-процессорами справляется довольно хорошо - как и было у вас в предыдущей статье.
Хорошая замена Celery для асинхрощины