При выполнении функции в Laravel запускаемой в Cron каждые 3 минуты, как избежать дублирования?

Question

[nopiveb839]

Всем привет!

Есть функция в Laravel, которую дергает Cron каждые 3 минуты. В этой функции, каждые 3 минуты берутся определенные записи из таблицы БД и их может быть любое количество.
И бывает так, что скрипт запустился но еще не закончил работу, а через 3 минут ызапустился новый и взял те же данные что и старый скрипт, которые он еще не обработал. В итоге получаем дублированные записи.
Как можно в Laravel этого избежать?

Спасибо!

Comments

[Дмитрий]

Который крон? Ларавеловский? Или системный?

[Константин Б.]

Laravel тут роли не играет. Это ваша архитектура страдает. Если допустим вы запустили крон задачу и в ней обрабатываете определенные записи запишите их id в массив и положите в кеш, по завершении задачи удалите из кеша их. В новом задании исключите те записи id которых есть в кеше

[nopiveb839]

Дмитрий, системный

[Дмитрий]

nopiveb839, ну я уже оба варианта расписал в ответе

[nopiveb839]

Константин Б., с кешем хороший вариант, а сколько можно хранить записей в кэше?

[Константин Б.]

nopiveb839, пока не удалите в конце задачи. Ну и время поставьте оптимальное какое-то. Нам то откуда знать) Ваше приложение

Answer 1

[Алексей Уколов]

Зависит от конкретного поведения, которое вам нужно.
Если хотите, чтобы скрипт выполнялся не чаще, чем раз в три минуты, но при этом всегда в один поток, то есть withoutOverlapping.
Если хотите, чтобы скрипт выполнялся ровно каждые три минуты, но при этом не брал уже обрабатываемые записи, то просто добавьте поле со статусом для каждой из них (он может быть как булевым, так и более сложным) и в самом начале помечайте взятые, а выбирайте только невзятые.

Comments

[nopiveb839]

как быстро laravel сможет пометить статусы у записей, если записей больше миллиона например?

[Дмитрий]

nopiveb839, а причем тут ларавел? это вопрос к тому в чем вы храните.

[Алексей Уколов]

Это никакого отношения не имеет к Laravel. Зависит от того а) какой конкретно запрос вы будете делать, б) какая структура у таблицы и какие в ней индексы, в) как настроена СУБД, г) какая именно СУБД используется, д) какое железо на сервере, е) и ещё куча других факторов.
Сразу говорю, что отвечать на эти вопросы не нужно, никто всё равно не сможет вам гарантировать какое-то время исполнения. Нужно просто написать код, запустить его и замерить, тогда вы получите точный ответ.

Но в случае сферического коня в вакууме обновить миллион записей - это не так уж и сложно, поэтому должно быть быстро. Но на всякий случай именно на этот кусок кода я бы поставил мьютекс (или блокировал таблицу средствами СУБД), чтобы второй процесс ждал разблокировки, без этого схема не будет надёжной.
А можно и вовсе использовать не статусы, а куда-то сохранять только id последней полученной записи, а следующий запрос делать от него, это будет ещё быстрее.

[nopiveb839]

Алексей Уколов, может есть статистика, тесты общие какие то? Основываясь на которых можно выбрать подход.

[Алексей Уколов]

На реализацию всех описанных сценариев в сумме нужны пара часов. И вы получите максимально релевантные для себя данные. "Статистика и тесты общие" они потому и общие, что для каждого конкретного проекта пользы не несут. В любом случае, если говорить о нормальном сервере с нормальной схемой - это от одной до десяти секунд примерно займёт, далеко не три минуты.

[nopiveb839]

Алексей Уколов, спасибо!

Answer 2

[Дмитрий]

Если используется ларавеловский планировщик:

$schedule->command('command')->withoutOverlapping();

если используется системный крон

*/5 * * * * flock -w 1 /tmp/command-lock php artisan command

Answer 3

[Александр Лыкасов]

Надо каким-либо способом делать очередь. Сейчас можно сказать стандартный способ это rabbitmq. Можно свою очередь сделать с хранением состояния в БД.
Можно простейший вариант с лок-файлом, когда скрипт при старте создаёт некий файл, а при окончании работы удаляет его. И скрипт не работает если такой файл есть.

Comments

[nopiveb839]

Очередь с хранением состояния в БД это хорошо, но как быстро будут сохраняться статусы в БД у большого количества записей?!
Лок файл это тоже хорошо, но необходимо не дожидаться окончания работы скрипта, а каждые 3 минут запускать.

[Александр Лыкасов]

Я, видимо, не понял суть вопроса. Получается вам нужно именно распараллелить обработку?

[nopiveb839]

Александр Лыкасов, именно так, данные приходят в реальном времени, необходимо запускать скрипт каждые 3 минуты, и чтобы данные не брались одни и те же в запущенных скриптах.

[Александр Лыкасов]

Тогда в рамках задачи можно предложить завести отдельную табличку, где каждая запись будет хранить данные обработки отдельного экземпляра вашего скрипта: что-то типа id, item_id_from, item_id_to, started_at
Т.е. скрипт при запуске резервирует под себя некий диапазон, а после обработки эту запись удаляет.
При таком подходе нагрузка на БД будет минимальной, а как я понял вас именно это беспокоит.

[nopiveb839]

Александр Лыкасов, спасибо большое!