LINUX.ORG.RU

Ответ на: комментарий от dem

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

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

bryak ★★★★ ()
Ответ на: комментарий от bryak

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

dem ★★ ()
Ответ на: комментарий от cobold

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

dem ★★ ()

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

ls-h ★★★★ ()
Последнее исправление: ls-h (всего исправлений: 1)

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

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

dimuska139 ()
Последнее исправление: dimuska139 (всего исправлений: 1)
Ответ на: комментарий от dem

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

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

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

dimuska139 ()
Последнее исправление: dimuska139 (всего исправлений: 2)
Ответ на: комментарий от dimuska139

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

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

dem ★★ ()
Ответ на: комментарий от dem

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

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

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

dimuska139 ()
Ответ на: комментарий от dimuska139

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

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

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

dem ★★ ()
Ответ на: комментарий от dem

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

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

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

dimuska139 ()