По идее, нужен какой-то шедулер и какая-то очередь, в которую будут падать задания, которые нужно выполнять и извлекать по завершению из этой очереди. Вот сижу и думаю, какой инструмент лучше применить
Когда я играл в Ingress я парсил сообщения из браузера. При большом потоке я падал (сервак был слабый). В итоге я создал 2 процесса. 1) Принимал сообщения, парсил и клал их в ZeroMQ 2) Второй клал их в постгрес. Скорость выросла в разы. И падеж закончился
Когда валится КУЧА сообщений коллектор не блокируется. Все накапливалось в ZeroMQ (кстати тоже капризная штука). Потом залп сообщений прошел и второй воркер очередь потихоньку разгребает…
А можно без Celery? Зачем оно вообще? Сделай директорию с задачами. Одна задача - один файл. Статус задачи - суффикс имени файла. Рабочие - процессы, которые висят на inotify. Кто первый взял, того и задача. Процесс забрал задачу в работу - переименовал файл в *.working.worker-id. Переименование файла это атомарная операция. Если случилась ошибка «файл не найден», значит забрал другой рабочий. Если упал, то когда поднялся найдёт свою задачу по worker-id.
Не нужно. База данных для этого не предназначена. Что за задача у тебя? Редис осваивать не хочется? Ну потрать час на него - нужная штука. Базу в качестве брокера очередей ни один адекватный человек использовать не станет. Такое в продакшене не юзают.
Вообще зачем тебе именно сельдерей? Для многих случаев годится и django-rq - в разы проще. Я бы с него начал.
Если ты имеешь в виду, что лучше не юзать RabbitMQ или RQ, а использовать в качестве брокера базу данных, то лучше так не делать. В интернетах полно инфы о том, почему юзать базу данных для таких целей - решение, не подходящее для продакшена.
Как раз использование базы данных вместо RabbitMQ или RQ - это как раз вариант «потому что я могу». Можешь - да, но делать так лучше не надо. Если у тебя решение на основе БД будет работать нормально при небольшой нагрузке, это не значит, что оно будет работать так же хорошо, когда она вырастет внезапно в 2-3 раза. Как это нормально подружить с ежедневными бэкапами базы, кстати?
RabbitMQ или RQ - это необходимые абстракции. Я не очень понимаю, о каких «течах» ты пишешь. Да, Celery раньше текла при некоторых обстоятельствах, но это, насколько я знаю, давно уже пофиксили. Если ты течью называешь баги, которые появляются в коде, когда добавляешь новые слои абстракции, то покрывай код тестами - и сведешь к минимуму вероятность этого.
Заказчик платит за время работы обычно. И написание тестов, соответственно, это время увеличивает. Это время надо закладывать. Можно заранее об этом предупредить заказчика. Если не согласен - получит парашу. Ну, чтобы потом претензий не было.
Можно не упарываться особо с процентом покрытия и договориться покрыть только самые важные функции проекта - тоже выход. И заказчику не сильно дорого, и лучше, чем ничего.
P.s. правда покрытие тестами кода, использующего очереди, обычно не самая простая задача.
правда покрытие тестами кода, использующего очереди, обычно не самая простая задача.
ВО. Почему не люблю Celery. Дебилы туда фигачат объект. Скажем User. Но не кладут User.id И бац пришло время выполнения таска. Тот достал User. А Юзера уже из базы удалили. Но об этом НИКТО не думает. Не проверяют. try except не вешают.
У нас была беда с рассылкой сообщений. Юзер мог поставить галку по почте и СМС. Сначала ему шел СМС, потом слалсь почта. И так вышло, что почта падала. Таск улетал обратно в очередь. Юзеру снова слался СМС и потом падала почта…. Дырявые абстракции.
Это не абстракции дырявые, а руки кривые) От этого никто не застрахован. Косяк разработчиков, а не очередей.
Сначала ему шел СМС, потом слалсь почта.
Это вообще должны быть независимые процессы. Я бы вообще сделал отдельными сервисами, внутри которых очереди: сервис для отправки смс и сервис для отправки имейлов. Тогда их можно использовать сразу из нескольких проектов и не писать одно и то же для каждого проекта.