Как наименее затратно мониторить в цикле наличие новой информации?

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

Barrakuda74 Ну оверхед на базу будет минимальный - вполне можно стучаться туда.
Другой вариант - записывать в кэш (memecache,Redis), читать оттуда.
В том же Laravel есть реализация таких очередей через базу и редис, можно подсмотреть там

RabbitMq, memecache, Redis, Laravel...

Неужели больше никак не сохранить одну строку с названием клиента?
Сразу почему-то вспомнился один комментарий из свежей статьи на хабре.
Объясните лучше чем так плоха простая запись в файл? Может я просто чего-то не знаю такого страшного про файлы, что все от них так шарахаются? Экзотики никакой нет на сервере, стоит стандартная связка apache, mysql и php.

Barrakuda74 Так если звонок один, клиент один, строчка одна, сервер один, скрипт один, оповещение одно - пишите на здоровье хоть в файл (в таком случае правда непонятно, зачем вообще куда-то писать, где отлавливается факт звонка - оттуда и слать сразу пуш)
В противном случае надо решать проблемы лока на чтение и на запись файла двумя скриптами
Первый скрипт (записывающий в файл) должен быть уверен, что ,когда он перезаписывает, к файлу никто не обращается в данный момент. Также ему желательно понимать, что данные в файле уже обработаны (пуш уже ушел)
Второму скрипту тоже нужно чтобы к файлу никто не обращался в данный момент (и по хорошему как-то пометить, что пуш отправлен)
Возникает вопрос, что делать в случае одновременного доступа ( один скрипт начал писать, второй пытается читать и получает от ворот поворот). Так можно легко и факт нового звонка проворонить, или пуш по нужному не послать
Что делать, если в случае такого конфликта пришел новый звонок и перезаписан старый, по которому не пришел пуш?
Что делать, если серверов 2, за балансировщиком, и файл создался в файловой системе на одном сервере, а читается на втором?
Руками можно решить вообще все что угодно, если понимать, какие проблемы это повлечет в случае роста нагрузки/функциональности/инфраструктуры

Очереди решают проблему масштабирования и роста запросов - звонков может быть хоть сотни на любых серверах - разгребаться и пушиться будут последовательно, ничто не потеряется, не перезапишется
База/Redis/Memcached в некотором роде решают проблемы одновременного доступа на чтение/запись (тут нужно смотреть в сторону уровней изоляции в бд, чтобы самому не накосячить), и работу на разных серверах с произвольным числом обработчиков

Вот как раз неделю назад для работы колл-цента на виртуальной АТС поднять такую архитектуру. Работает как часы, масштабируется примерно бесконечно)

(в таком случае правда непонятно, зачем вообще куда-то писать, где отлавливается факт звонка - оттуда и слать сразу пуш)

Как это непонятно, один маленький скрипт отлавливает события телефонии и пишет их в БД, другой общается с SSE. Из первого не передать сообщение клиенту, он не прослушивается SSE.

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

$fp = fopen ("path_to_file","a");//открытие 
flock ($fp,LOCK_EX);//блокировка файла 
ftruncate ($fp,0);//УДАЛЯЕМ СОДЕРЖИМОЕ ФАЙЛА 
fputs($fp ,"$data\r\n");//работа с файлом 
fflush ($fp);//очищение файлового буфера и запись в файл 
flock ($fp,LOCK_UN);//снятие блокировки 
fclose ($fp);//закрытие

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

Хотя... я вот теперь так подумал, может записывать в mysql не такая уж и плохая затея)))

Barrakuda74,

Как это непонятно, один маленький скрипт отлавливает события телефонии и пишет их в БД, другой общается с SSE. Из первого не передать сообщение клиенту, он не прослушивается SSE.

а это уже и вырисовывается по сути очередь с хранением в базе, которая реализована уже в кучке библиотек и протестирована, и самостоятельно писать для работающего проекта уже не обязательно. Одна сторона пишет в базу ( publish message), другая разгребает и обрабатывает (consume message). В качестве транспорта - MySql

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

Александр Новиков, Спасибо, Александр. Всё понятно.