Mysql триггер / события против Cronjob

Question

У меня есть веб-сайт аукциона, который позволяет моим пользователям размещать неограниченное количество автоматических торгов.

Для отслеживания этих автоматических торгов что-то должно проверять базу данных каждую секунду.

Мой вопрос: лучше ли использовать триггерные события mysql или использовать cronjob каждую минуту, который выполняет 60-секундный php-скрипт с циклическим выполнением.

Если я использую триггерные события mysql,сотни событий складываются друг с другом и запускаются в разное время.Это вообще возможно ??И не нагрузка сервера собирается быть огромной.Я где-то слышал, что база данных будет заблокирована во время запланированного события.Кстати, я использую таблицы innoDB.

Надеюсь, кто-нибудь сможет пролить свет на этот топик.

С уважением!

Answer 1

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

Сказав это: поскольку ваши системы должны реагировать на действия пользователя, технически предпочтительным способом сделать это является использование триггеров. На практике это может привести к проблемам с производительностью, когда ваш сайт сильно загружен, хотя использование запланированного события может вызвать те же проблемы.

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

Answer 2

Лучше всего запустить отдельный скрипт, который работает вечно и следит за вашей базой данных. Таким образом, вам не понадобится cron. Ни огромное количество триггеров.

Но вы можете пересмотреть весь свой вопрос. Нет необходимости обновлять ставки каждую секунду. Вам нужно заполнить последние x минут / часов только тогда, когда кто-то фактически указывает свой браузер на аукцион или делает ручную ставку. Если это все автоматические ставки, вы можете легко рассчитать перемотку вперед назад.

Answer 3

Вы можете использовать скрипт bash & shell для выполнения этой процедуры автоматического назначения ставок. По этой ссылке вы получите представление: Bash скрипт, который запускает php файл каждые 5 секунд

Answer 4

Возможно, я бы смоделировал решение вашей проблемы с автоматическими ставками немного по-другому:

Как насчет событийного подхода? Вы сохраняете запросы автоматической ставки ваших пользователей, и если кто-то действительно делает ставку на объект, вы обрабатываете ранее поставленные в очередь автоматические ставки.

Это имеет следующие преимущества:

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