Стабильность batch операций

[stalxed]

Хотелось бы узнать о практиках обеспечения обработки больших таблиц данных.
Т.е. такие операции как пересчитать всем скидку, удалить множества товаров(и зависимых дынных) от конкретного поставщика, етс.

Сейчас такие задания ложатся в таблицу jobs, и эти задания берёт cron.
Но задание может выполняться 10-20 минут, а об успешности операций можно судить только по анализу лога.
Бывает сыпется, то памяти не хватило, то ещё что-то.
Необходима большая отказоустойчивость и автономность.

Пожалуйста, поделитесь опытом из собственной практики подобных операций!
Неужели всё сводится к тому, чтобы найти все баги?
И нельзя чего-то более умного придумать...

 

[DiMA]

в таблице task делаешь колонки:
диапазон, статус, время начала, время окончания, кол-во попыток, номер треда

всех юзеров объедини логически в группы, по 100 штук, в поле диапазон пишешь их
за один проход крон берет любой необработанный еще диапазон и в цикле конвертит этих 100 объектов
в статусе и времени пишется инфо о таких попытках
если крон виснет, то в статусе будет "запущено", время начала сильно устарело (на 5 минут, например), время окончания нулевое - следовательно, такой таск завис, его обрабатывать повторно

в начале работы формируешь такую таблицу, окончанием служит момент, когда все статусы выдают "готово"

 

[AmdY]

Первым делом стоит выбросить cron, он формирует плохие привычки и желание есть большой ложкой из-за чего растёт большинство проблем.
Возьми инструмент предназначенный для очередей, будет проще работать и следить за очередью. И подход к разбиению задач будет другой, будешь дробить их на маленькие, чтобы запускались по мере возможности, а не по таймеру.

 

[флоппик]

AmdY, а ты кого для очередей используешь?

 

[AmdY]

redis, возможно, не лучший инструмент, но чтобы не плодить энтропию подходит.

 

[флоппик]

Ну что бы хранить очередь — редис. А запускать воркеров откуда тогда? Тоже по крону?)

 

[stalxed]

Первым делом стоит выбросить cron, он формирует плохие привычки и желание есть большой ложкой из-за чего растёт большинство проблем.
Возьми инструмент предназначенный для очередей, будет проще работать и следить за очередью. И подход к разбиению задач будет другой, будешь дробить их на маленькие, чтобы запускались по мере возможности, а не по таймеру.

Я думал о сервере очередей.

Но во первых возникает вопрос как у флоппик, кто запускает воркеры.

И второй вопрос, а как создавать задания именно для батч операций.
Например, необходимо обработать 50000 клиентов, пересчитать накопительную скидку.
Создавать 50000 записей в сервере очередей? Или создать 50 записей, в каждой из которых хранятся 1000 id клиентов?
Но очередь ведь работает атомарно, т.е. взял задание из очереди, выполнил, сказал очереди его удалить. Смущает, что или 1000 выполняются сразу все 1000 идут нафиг.
Хотя, наверное так?:
1) Взял из очереди задание с 1000 id
2) Начал транзакцию БД
3) Обработал 1000 записей
4) Commit транзакции
5) Говорим очереди, что задание завершилось успешно и можно его удалять
Такой алгоритм работы? Или есть схемы умнее?

 

[флоппик]

stalxed, если записи об атомарных действиях, то 50000 записей, конечно. Если воркер захочет, может 1000 раз выдернуть запись из очереди.

 

[stalxed]

флоппик, но как будет выглядеть операция добавления в очередь?

1) В интерфейсе пользователь кликает пересчитать скидки активным пользователям.
2) Совершаем выборку SELECT id FROM clients WHERE state=1
3) Проходим по массиву id, и 1 id = 1 задание в очереди

Но 50000 заданий поставить в очередь.... эта операция сама по себе должна выполняться с крона? Разве нет?

 

[флоппик]

Заполнение очереди задачами тоже может быть задачей )

 

[Sufir]

А запускать воркеров откуда тогда? Тоже по крону?)

Актуальный вопрос. Демон какой-то? Как вы это делаете, товарищи?

 

[флоппик]

Ну у меня демон, да. Но у меня там своя специфика немножко.

 

[MiksIr]

А крон тоже демон

 

[stalxed]

Заполнение очереди задачами тоже может быть задачей )

Охх.... выглядит немного безумно.

 

[AnrDaemon]

Охх.... выглядит немного безумно.

Почему же? Вполне себе стратегия.

 

[флоппик]

stalxed, что бы градус восприятия поднять, можно почитать про Map-Reduce: https://ru.wikipedia.org/wiki/MapReduce Оно не про демоны, просто про такой подход в целом.

 

[AmdY]

Ну что бы хранить очередь — редис. А запускать воркеров откуда тогда? Тоже по крону?)

Зачем крон, поднимал демона, попираю его супервизором, он форкает воркеров. Сейчас же laravel такое из коробки умеет, но пока но практике не использовал, задачи разгребать очередь давно не стояло.

 

[stalxed]

stalxed, что бы градус восприятия поднять, можно почитать про Map-Reduce: https://ru.wikipedia.org/wiki/MapReduce Оно не про демоны, просто про такой подход в целом.

Спасибо, интересно.

 

[флоппик]

Зачем крон, поднимал демона, попираю его супервизором, он форкает воркеров. Сейчас же laravel такое из коробки умеет, но пока но практике не использовал, задачи разгребать очередь давно не стояло.

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

 

[MiksIr]

Имхо, свой демон нужен если нужно минимизировать задержку между задачей и исполнением. Ну или просто задачи частые и легкие - что бы экономить на подъеме окружения.
А иногда подняться и пересчитать базу - крона хватает вполне.