Каков наилучший способ постоянно проверять обновление таблицы MySQL?

Question

По некоторым причинам (которые, я думаю, не в этом суть моего вопроса, но если это поможет, спросите меня, и я могу описать, почему), мне нужно постоянно проверять таблицы MySQL на предмет новых записей. Если появятся какие-либо новые записи, я хочу сделать некоторые связанные действия, которые сейчас не важны.

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

На данный момент у меня есть это:

$new_record_come = false;

while(! $new_record_come) {
   $sql = "SELECT id FROM Notificatins WHERE insert_date > (NOW() - INTERVAL 5 SECONDS)";
   $result = $conn->query($sql);
   if ($result)
   {
      //doing some related actions...
      $new_record_come = true;
   }
   else
   {
      sleep(5); //5 seconds delay
   }
}

Но я беспокоюсь, что, если я получу тысячи пользователей, он отключит сервер, даже если сервервысокая цена!

Есть ли у вас какие-либо советы, чтобы повысить производительность или даже полностью изменить способ или даже изменить тип запроса или любое другое предложение?

Answer 1

Опрос базы данных является дорогостоящим, поэтому вы правы, опасаясь этого решения.

Если вам нужно масштабировать это приложение для обработки тысяч одновременно работающих пользователей, вам, вероятно, следует подумать о дополнительной технологии, которая дополняетСУРБД.

Для этого я бы предложил использовать очередь сообщений. После того, как приложение вставит новое уведомление в базу данных, оно также опубликует элемент в теме в очереди сообщений. Обычно первичный ключ (id) - это элемент, который вы публикуете.

Тем временем другие приложения прослушивают тему. Им не нужно делать опрос. Работа очередей сообщений заключается в том, что клиент просто ждет, пока в очереди не появится новый элемент. Ожидание вернет элемент.

Комментарий, предложивший использовать триггер для вызова скрипта PHP. Это не будет работать, потому что триггеры выполняются, пока транзакция, которая их породила, еще не зафиксирована. Так что если триггер запускает скрипт PHP, который, вероятно, должен прочитать запись из базы данных. Но незафиксированная запись не видна ни в одном другом сеансе базы данных, поэтому скрипт PHP никогда не сможет прочитать данные, о которых он был уведомлен.

Answer 2

Это может быть невозможно с вашей текущей конструкцией системы, но как насчет того, чтобы вместо использования триггеров или пульса непрерывно опрашивать базу данных, когда вы идете туда, где происходят обновления и т. Д., И оттуда выполняете другой код? Таким образом, вы можете избежать непрерывного опроса базы данных, и код будет срабатывать ТОЛЬКО ЕСЛИ кто-то инициирует запрос?

Answer 3

Другой угол (намного проще, чем очередь сообщений, я думаю):

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

Допустим, первичный ключ называется 'postid'.

У меня былфайл, содержащий последнюю версию.

Я обновлял его с каждой новой записью в tblposts, поэтому он всегда содержит самые последние сообщения.

Сценарии опроса на стороне клиента просто извлекали этот файл (не используйте PHP, просто позвольте Apache обслуживатьэто намного быстрее: назовите его lastpostid.txt или что-то в этом роде.

Клиент сравнивает свой внутренний последний постид. Если это больше, клиент запрашивает те после последнего. Этот шаг включает запрос.

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

(Не уверен, что это сработает в вашей ситуации, поскольку предполагается, что все большее число означает «новее».)