Приветствую! Помогите решить сложный для меня вопрос.
Вот на моём сайте написан модуль, в котором каждый пользователь может создать турнир. Все созданные турниры имеют несколько состояний: в ожидании, стартовал, завершён.
Я хочу сделать так, чтобы каким-то образом шёл постоянный селект БД каждого незавершённого турнира, и после условий по времени, турниры бы обновляли свои данные с "в ожиданни" до "стартовал", и со "стартовал" до "завершён".
Эту задачу, на сколько я понимаю, можно сделать как через cron, так и через планировщик задач mysql. Посоветуйте что лучше использовать? И почему?
Лучше расскажите, зачем вам "чтобы постоянный селект".
Чтобы определить статус турнира, достаточно два поля-таймштампа: начало и конец.
Причем определяться это будет, когда понадобится, а не разводя энтропию.
KarambyG, это понятно, что вы считаете это нужным. Я предложил подумать - зачем.
Когда реально понадобится статус турнира - он легко определяется. На кой хрен для этого теребить базу каждую минуту?
Adamos, Представь ты находишься на главной странице. Перед тобой список всех турниров. И среди них есть турнир, который имеет статус "в ожидании", а по факту то он уже давным давно начался! А статус не обновился потомучто на него никто не заходил давно. Понял теперь?
KarambyG, подозреваю, для формирования главной страницы этот список читается из базы. При этом достаточно двух полей - начала турнира (заполняется при создании) и конец (заполняется при завершении), чтобы по ним и текущему времени определить его статус. Более того - если требуется, менять этот статус прямо на странице, отслеживая текущее время js-скриптом.
Adamos, у меня по завершению турнира ещё призы выдаются... и хотелось бы чтобы прызы выдавались сразу же после завершения турнира, а не только тогда, когда ктото зайдёт на главную страницу турниров.
KarambyG, а что, при подведении итогов никто еще не следит за fair play и не гоняет читеров?
Ну, этот обработчик можно повесить на крон. Если, конечно, призы не таковы, что до первого зашедшего за призом их можно и не обрабатывать.
KarambyG, я плохо отношусь к энтропии. Запланированные в вопросе действия бессмысленны. Вот всплывшие по ходу обсуждения призы - да, могут оправдывать действия по расписанию. Только скорее не отдельный скрипт конкретно под эту задачу, а очередь обработки с механизмом исключения задвоения исполняемых задач.
KarambyG, такие вещи не делаются по-простому: о, надо раздать призы, начинаем раздавать. Потому что если не управиться за минуту, крон снова запустит скрипт, и он снова скажет "о, надо раздавать призы".
Надо создать задачу и, когда она пошла на обработку, отметить это. Чтобы следующий скрипт увидел, что заново создавать и обрабатывать задачу не следует, даже если первый почему-то призадумался. А если задача уже час на обработке, но все еще не отмечена, как выполненная - хорошо бы сообщить вебмастеру, что что-то пошло не так...
Очередь задач это называется.
Полностью согласен с товарищем Adamos - никакие периодические действия тут нахрен не нужны. Использование планировщика бессмысленно, а отдельное поле статуса избыточно.
с планировщиком задач mysql знаком? может для моего случая лучше его использовать вместо крона?
Да, если бы задача действительно требовала периодически выполняемого действия, встроенный планировщик MySQL был бы правильным решением, а внешний CRON - решением избыточным.
хотелось бы чтобы прызы выдавались сразу же после завершения турнира
Выдача призов НИКАК не связана со статусом турнира. Она связана только с заданной точкой времени. Просто в данном конкретном случае значение этой точки хранится в поле даты-времени конца турнира таблицы туриров.
И вот для организации НЕЗАВИСИМОЙ от процесса определения статуса турнира процедуры раздачи призов действительно нужно использовать планировщик. И именно планировщик MySQL.
Akina, а планировщик mysql, я так понимаю ты указываешь дату и время, когда турнир завершится, им будут назначены всем призы, и когда это время наступает, то призы раздаются. А если сервер в это время залагал, или вообще упал.
В итоге, после перезапуска сервера, этот планировщик уже никогда не сработает? так как время - когда нужно было раздать призы - уже прошло. А сам планировщик будет висеть в планировке вечно. Как тогда быть с такой проблемой?
Akina, тут еще большой вопрос, что именно включает в себя процедура раздачи призов.
Если обращение к API кассы, например, то планировщик БД как бы мимо ;)
а планировщик mysql, я так понимаю ты указываешь дату и время, когда турнир завершится, им будут назначены всем призы, и когда это время наступает, то призы раздаются. А если сервер в это время залагал, или вообще упал.
Неверно.
Планировщик регулярно выполняет event procedure (например, ежеминутно). Процедура проверяет наличие записи, которая соответствует двум условиям. Первое - для неё наступил момент раздачи призов, однако отсутствует пометка о завершении раздачи. Второе - процедура раздачи для в данный момент не выполняется Если такая запись имеется - для неё запускается экземпляр процедуры раздачи призов. Этот экземпляр должен обрабатывать любые ситуации - как первый запуск, так и случай, когда экземпляр процедуры уже запускался, но по некоей причине не выполнился до конца.
тут еще большой вопрос, что именно включает в себя процедура раздачи призов.
Тут нет вопроса.
Планировщик MySQL выполняет все необходимые операции в рамках сервера БД и подготавливает все необходимые для раздачи призов данные. А потом уже PHP через CRON или иным способом поллит БД, обнаруживает сведения о необходимости раздачи, и в соответствии с ними выполняет внешние для MySQL операции, включая и общение с кассой, буде нужно.
Akina, если пых-скрипты все равно выполняются по крону, не вижу смысла усложнять работу сайта (например, для того, кто в ней будет разбираться) разнесением таких действий по крону и БД. Даже если БД может сделать что-то эффективнее.
Овчинка, выделка и все-все-все.
Adamos, это где же усложнение-то? скорее наоборот.
Вы, как обычно любят пэхапэшники, валите всё в одну кучу. В то время как раздача призов - это не один процесс, а несколько связанных по обработке данных процессов, связанных тем, что следующий в цепи начинает выполняться только после завершения предыдущего и используя полученные этим предыдущим данные. В то же время по выполнению они абсолютно независимы. Раздавать призы можно и через секунду после расчёта призовых, и через неделю. Главное, чтобы всё уже было рассчитано.
Те этапы, которые занимаются детектированием наступления времени раздачи, расчётом необходимых параметров раздачи, проверкой незавершённости предыдущего инстанса раздачи и восстановлением при обнаружении - они выполняются исключительно на MySQL данных, и потому средствами MySQL и его планировщика. И если выполнять их средствами внешнего планировщика - то это плюс нагрузка на сервер и ноль профита. Плюс снижение надёжности системы, потому что увеличилось количество потенциально сбойных точек .
А вот этапы, которые занимаются фактической раздачей на основе рассчитанных параметров - они выполняются средствами PHP, потому как у MySQL нет штатных инструментов взаимодействия с внешним API. Будь такой инструмент (например, подключена внешняя UDF, которая способна выполнить общение с кассой через её API) - и этот этап тоже выполнялся бы на стороне MySQL и его планировщиком.
Akina, ну да, я смотрю на ситуацию с точки зрения похапешника, которому свалилась довольно обычная задача: разобраться, что не так с вот этим незнакомым сайтом.
Adamos, пэхапэшник, который ни ухо ни рыло за пределами PHP - это норма. А вот любые отклонения от этого - увы, экзотика. Ещё хуже дела обстоят, если это не чистый пэхапэшник, а спец по некоему фреймворку.
Средний
