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

Question

[Barrakuda74]

Т.е. вот есть цикл в server sent events, он проверяет каждые 500мс нет ли звонка от клиента. Как появляется, передаёт эту информацию в браузер менеджеру. Так вот вопрос, куда эту информацию записывать? Ясно что не в БД, это слишком затратно к ней обращаться каждые полсекунды. А куда лучше? Просто записывать в какой-нибудь файл calls.txt и считывать каждые полсекунды оттуда первую строку? Нормально ли так часто обращаться к файлу? или может другие какие-то хранилища быстрые есть в php?

Answer 1

[Александр Новиков]

RabbitMq + Consumer на PHP
Поступил звонок -> Пуш сообщения в RabbitMq -> Свободный консьюмер обрабатывает и пушит уже в браузер по websocket
Легко масштабируется если нагрузка станет больше (просто добавить консьюмеров)
Но вообще нагрузка "каждые полсекунды" для базы - не нагрузка вовсе

Comments

[Barrakuda74]

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

[Александр Новиков]

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

[Barrakuda74]

RabbitMq, memecache, Redis, Laravel...

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

[Александр Новиков]

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

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

[Иван Шумов]

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

[Barrakuda74]

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

Как это непонятно, один маленький скрипт отлавливает события телефонии и пишет их в БД, другой общается с 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 звонков в день, думаю можно обойтись даже таким решением в лоб. Поправьте если не прав.

[Barrakuda74]

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

[Александр Новиков]

Barrakuda74,

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

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

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

[Barrakuda74]

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

Answer 2

[Олег]

> есть цикл в server sent events, он проверяет каждые 500мс
Почему сами лезете к апи ? Калбаки есть ?
> Ясно что не в БД,
Нет файлы хуже .
> считывать каждые полсекунды оттуда первую строку?
У вас фронт насилует бак каждые полсекунды аякс запросом ?

Как я вижу все решение

используем WebPush https://fcm.googleapis.com/fcm/send

Виртуальной атс говорим урл для уведомлений.

При его вызове, разбираем данные. Заносим в базу для статистики или для других целей. Шлем уведомление .
Обычно оно выскакивает через 250мс.

В общем гуглите. Примеров в сети достаточно.

Comments

[Barrakuda74]

> есть цикл в server sent events, он проверяет каждые 500мс
Почему сами лезете к апи ? Калбаки есть ?

Неправильно выразился. цикл конечно на сервере, не в sse.

> Ясно что не в БД,
Нет файлы хуже .

А БД разве не тот же файл, только большой?

используем WebPush https://fcm.googleapis.com/fcm/send

Зачем здесь сторонний сервис? Нам своего сервера чтоли мало для хранения одной строки с названием клиента?

[Иван Шумов]

Barrakuda74, если бы бд это был просто большой файл то такую производительность они бы не выдавали. Да, данные в любом случае хранятся на диске, но только хранятся

[Олег]

При чем тут хранение строки на сервере ?

Задача Проинформировать менеджера о звонке клиента на офисную линию.
Т.е. на его компе должно выскочить окошко.
-------------------------------------------------------------
Звонит Шура. Заказывал вчера спортивные гири.
-------------------------------------------------------------

fcm - это технология посылки сообщения на устройство получателя.
Chrome на персональном компьютере или мобильный андроидофон.