Можно ли использовать celery без rabbitmq и redis? Database only

Я разрешаю.

Если хочешь задрочить базу запросами то можно

А смысл вообще использовать Celery? Лишняя прослойка которая доставляет массу проблем. https://habr.com/ru/post/483014/

А в чем может быть проблема с RMQ или тем более редисом? Они и в установке и в поддержке - простые как полено.

Эта тема создана по мотивам: Стратегия отложенной записи

По идее, нужен какой-то шедулер и какая-то очередь, в которую будут падать задания, которые нужно выполнять и извлекать по завершению из этой очереди. Вот сижу и думаю, какой инструмент лучше применить

В поставке нет смузи

Когда я играл в Ingress я парсил сообщения из браузера. При большом потоке я падал (сервак был слабый). В итоге я создал 2 процесса. 1) Принимал сообщения, парсил и клал их в ZeroMQ 2) Второй клал их в постгрес. Скорость выросла в разы. И падеж закончился

А zeromq для чего в этой схеме, если в конечном итоге все в базу пишется?

Когда валится КУЧА сообщений коллектор не блокируется. Все накапливалось в ZeroMQ (кстати тоже капризная штука). Потом залп сообщений прошел и второй воркер очередь потихоньку разгребает…

А можно без Celery? Зачем оно вообще? Сделай директорию с задачами. Одна задача - один файл. Статус задачи - суффикс имени файла. Рабочие - процессы, которые висят на inotify. Кто первый взял, того и задача. Процесс забрал задачу в работу - переименовал файл в *.working.worker-id. Переименование файла это атомарная операция. Если случилась ошибка «файл не найден», значит забрал другой рабочий. Если упал, то когда поднялся найдёт свою задачу по worker-id.

но зачем?

Не нужно. База данных для этого не предназначена. Что за задача у тебя? Редис осваивать не хочется? Ну потрать час на него - нужная штука. Базу в качестве брокера очередей ни один адекватный человек использовать не станет. Такое в продакшене не юзают.

Вообще зачем тебе именно сельдерей? Для многих случаев годится и django-rq - в разы проще. Я бы с него начал.

Селери часто вносит такие косяки, что потом неделю их ищешь. А еще https://a32.me/ru/2013/03/ne-dajte-astronavtam-arhitektury-vas/

Я и говорю, что возьми RQ, а не Celery. Статью прочитал, но не понял, к чему это))

К тому, что слои абстракции часто протекают. Их надо применять с осторожностью, а не потому что «я могу»…

Если ты имеешь в виду, что лучше не юзать RabbitMQ или RQ, а использовать в качестве брокера базу данных, то лучше так не делать. В интернетах полно инфы о том, почему юзать базу данных для таких целей - решение, не подходящее для продакшена.

Как раз использование базы данных вместо RabbitMQ или RQ - это как раз вариант «потому что я могу». Можешь - да, но делать так лучше не надо. Если у тебя решение на основе БД будет работать нормально при небольшой нагрузке, это не значит, что оно будет работать так же хорошо, когда она вырастет внезапно в 2-3 раза. Как это нормально подружить с ежедневными бэкапами базы, кстати?

RabbitMQ или RQ - это необходимые абстракции. Я не очень понимаю, о каких «течах» ты пишешь. Да, Celery раньше текла при некоторых обстоятельствах, но это, насколько я знаю, давно уже пофиксили. Если ты течью называешь баги, которые появляются в коде, когда добавляешь новые слои абстракции, то покрывай код тестами - и сведешь к минимуму вероятность этого.

Если ты имеешь в виду, что лучше не юзать RabbitMQ или RQ

Я имею ввиду что не надо использовать Celery там где вы не знаете ЗАЧЕМ он вам нужен.

то покрывай код тестами - и сведешь к минимуму вероятность этого.

Вот сегодня я пишу тесты. Вы попали в самое оно… А ведь заказчик часто не платит за тесты

Ну это понятно, что если нужны те же периодические таски, то проще Кроном воспользоваться, например. Ну, если они не требуются чаще, чем раз в минуту.

Заказчик платит за время работы обычно. И написание тестов, соответственно, это время увеличивает. Это время надо закладывать. Можно заранее об этом предупредить заказчика. Если не согласен - получит парашу. Ну, чтобы потом претензий не было.

Можно не упарываться особо с процентом покрытия и договориться покрыть только самые важные функции проекта - тоже выход. И заказчику не сильно дорого, и лучше, чем ничего.

P.s. правда покрытие тестами кода, использующего очереди, обычно не самая простая задача.

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

ВО. Почему не люблю Celery. Дебилы туда фигачат объект. Скажем User. Но не кладут User.id И бац пришло время выполнения таска. Тот достал User. А Юзера уже из базы удалили. Но об этом НИКТО не думает. Не проверяют. try except не вешают.

У нас была беда с рассылкой сообщений. Юзер мог поставить галку по почте и СМС. Сначала ему шел СМС, потом слалсь почта. И так вышло, что почта падала. Таск улетал обратно в очередь. Юзеру снова слался СМС и потом падала почта…. Дырявые абстракции.

Если он захочет разнести воркеров на несколько серверов, то это так просто не сработает.

Это не абстракции дырявые, а руки кривые) От этого никто не застрахован. Косяк разработчиков, а не очередей.

Сначала ему шел СМС, потом слалсь почта.

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