Предположим что есть сайт, и админка у сайта. Через админку - можно создать аукцион для клиентов сайта, которые в дальнейшем с ним будут взаимодействовать при его открытии.
То есть я через админку создаю аукцион, который например должен начаться через 24 часа. Люди которые заходят на сайт видят инфу о том что вот есть такой то такой то аукцион, и когда он стартанёт ( счётчик до старта аукциона ).
Вопрос в том - как этот аукцион запустить ? При создании аукциона, создаётся просто запись в таблице которая отвечает за создание аукционов, то есть например минимальные данные об аукционе и дата старта.
Для решения это проблемы, у меня голове крутилось 2 варианта:
1 - крон который запускает файл на бэкенде каждые 1 или 2 секунды , сам же этот файл - делает подключение к бд, и смотрит таблицу и сверяет даты у каждой записи, если аукцион может быть создан, создаёт в основной таблице с аукционами запись об аукционе ( который уже то есть работает и с ним пользователи могут взаимодействовать )
2 - просто запустить отдельный сервер, который на бэке через просто интервал делает тоже самое что и в первом варианте
Оба варианта для меня сомнительны, мне кажется что я возможно делаю что-то неправильно или что-то упускаю. Хотелось бы узнать, как было бы лучше для данной ситуации ?
P.S так же я знаю что можно крон какой-то запустить на уровне вообще базы данных, но этот вариант не особо отличается от первых двух, плюс к тому же из инета вычитал что лучше на уровне бд не делать каких-то кронов и т.д.
Так же таблицы которые описаны в вопросе, они примерные, скорее всего будут чуть другие.
что такое "запустить" аукцион? зачем его вообще запускать? почему бы сразу не дать возможность с ним "работать", просто отсеивая "рабочие" запросы до времени запуска
Everything_is_bad, ладно за место аукциона, пусть будет магазин и время до его открытия
в общем проблема вся в том что при старте магазина, должны создаваться другие записи в других таблицах которые связаны с этим магазином и всех его участников, которые например зарегистрировались в поход этого магазина
Для правильного вопроса надо знать половину ответа
А что мешает сразу создавать запись аукциона с указанием времени его проведения и при запросах сравнивать его с текущим временем? И не надо плодить лишних таблиц и задач.
видимо да бестолково я написал вопрос, хоть и старался
в общем проблема вся в том что при старте аукциона, должны создаваться другие записи в других таблицах которые связаны с этим аукционом и всех его участниках
создать эти записи одновременно с записью самого аукциона?
и обновлять их при действиях участников, если участник отменил регистрацию до старта аукциона например и т.д
понял, ну в целом да это ответ на вопрос, вообще после того как я задал вопрос, у меня из головы всё вылетело, а именно причина по которой было не всё так просто, если потом вспомню в чём была ещё проблема то отпишу в коммент
Rsa97, многие ко многим ( один участник может быть сразу в нескольких аукционах, и у одного аукциона может быть несколько участников ), с промежуточной таблицей, да проблема не в этом, в том что с этим аукционом и с этими участниками ещё несколько таблиц связаны, например при старте аукциона должна создаваться комната на сокетах, в общем подумаю, но в целом примерно такое решается не через планировщики ? и не через отдельный сервер например который отслеживает таблицу каждую секунду ? были подобные ситуации/кейсы c отслеживанием таблицы ?
Rsa97, хотя я ща додумался как создавать эту комнату, без всяких кронов и интервалов
просто когда пользователь входит в комнату - идёт проверка в таблице в бд, о том что стартовал ли этот аукцион - если стартовал и если комната не создана - создать и поместить в неё пользователя, и мб это всё через транзакцию
szQocks, Скорее, многие-ко-многим.
С сокетами всё зависит от нагрузки. Пока одновременно идёт десяток-другой аукционов, скорее всего справится и один WS-сервер, который просто будет проверять активность аукциона, возможно, кэшируя себе при первом запросе те, которые ожидаются в ближайшее время или уже идут. Примерно так:
- пришёл запрос с id аукциона.
- если аукциона нет в кэше, то запрашиваем его из БД.
- если аукцион начнётся в течение 10 минут или уже идёт, заносим его в кэш.
- проверяем время аукциона.
- если аукцион неактивен, даём отказ.
- если аукцион активен, то обрабатываем запрос.
- периодически удаляем из кэша все закончившиеся аукционы.
через крон - вполне нормальное решение. Только:
1) стандартный крон запускается не чаще раза в минуту, а не секунду
2) замерьте, сколько времени занимает запуск аукциона, чтобы не было наложения.
Решение проблемы второго пункта - очереди сообщений ( RabbitMQ и прочие варианты). У Вас висит воркер, который мониторит некоторую очередь непрерывно. А в кроне стоит скрипт-публикатор , который проверяет, какие аукционы надо запустить, публикует в очередь задание по запуску каждого аукциона, а у самого аукциона помечает, что задание поставлено.
Таким образом, неважно, сколько времени занимает старт одного аукциона, к тому же воркеров может быть несколько. А публикация задания - существенно более простая задача, делается за секунду.
Простой
Средний
Простой
