Живое обновление или как пользоваться WebSocket

Рейтинг: 1Ответов: 1Опубликовано: 16.02.2015

Всем доброго времени суток.

Я уже просто в отчаянии, я перечитал кучу литературы, пересмотрел кучу видосиков, и знаете что? Я ничего не понял. Одни пишут устанавливай Node.js, потом какую-то MongoDB, другие через C# пишут какие-то краказяблики. Дело в том, что я уже написал свой MVC, движок на PHP, а как я понял, если устанавливать Node.js и ту страшную базу данных, то нужно переписывать всю логику, а это значит, что вся моя работа просто коту под одно место, мне такая перспектива не очень.

В общем, расскажите тупенькому, на примере, как сделать живой чат, который будет выводить сообщения сразу по поступлению, без использования Node.js и прочей нечисти, или это невозможно? Буду предельно благодарен. Спасибо за внимание. :)

P.S. "Без всякой нечисти" я имею в виду, чтоб участие принимали только php, jQuery, javascript, mysql ну или там другие библиотеки, которые нужно подключать, а не устанавливать и танцевать перед ними с бубном.

Ответы

▲ 2Принят

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

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

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

Теперь про то, как с этим жить дальше. Можно, конечно, пытаться прикручивать все именно к центральному серверу, но если мои доводы, приведенные выше, убедительны, можно пойти другими путями. Я делал так: рядом с основным тяжелым сервером поднимается легкий серверочек, который обрабатывает исключительно сокеты. Он может быть устроен как угодно, у меня там был python + tornado, к примеру. Ну так вот, все дело в том, что общаться с основным сервером ему не особенно нужно. У вас есть что-то, что идет через сокеты. Чатик ли это, или поток видео, не суть. Главное, что оно идет только через сокеты. А основной сервер рендерит странички, делает какую-то логику. И если не смешивать одно с другим, все будет хорошо. Нужно просто четко осознавать, за что у вас отвечают сокеты, а за что — основной сервер. Ну а если уж очень нужно, можно наладить общение с ними, какие-то сигналы.