Пишу сайт с элементами социальной сети

Здравствуйте. Пишу сайт с элементами социальной сети. В настоящее время у пользователей имеется возможность обмениваться личными сообщениями. Так вот сейчас нужно сигнализировать пользователю о поступлении ему нового сообщения. Как это лучше сделать? Делать ajax-запросы или есть какой то другой способ? Как например это реализуется в социалках?

Вариантов много AJAX, Soket.IO, node.js, RabbitMQ
Все зависит от желания

-----
просто ?: сложно

Нашел вот такую статью http://www[dot]ibm[dot]com/developerwork[dot][dot][dot]ndex[dot]html#N101FA .
Заинтересовал вариант long polling. Только вот один момент пока не ясен:


Что такое mvn?

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

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

(Отредактировано автором: 19 Ноября, 2013 - 10:50:54)

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

не обязательно физический - это может быть и виртуальный - он дешевле

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Нужно будет купить у хостера две площадки со своими тарифами? Я правильно понял?

Зачем две

Как раз стоит такая же задача. И решаю именно таким способом

Что то я запутался. Можете по подробнее объяснить как это будет стыковаться?

все просто. Через PHP публикуем сообщение на редис. В NodeJS подписиваемся на сообщения от редиса. Если поступило - шлем его клиенту.
Что нужно учесть:
1. открывать соединение нужно только в одной вкладке иначе можно упереться в лимит одновременных конектов в браузере(де и не хорошо). Остальные же слушают LocalStorage собитие onstorage
2. нужно хранить инденификаторы сессий в redis чтобы знать кому именно слать сообщение из nodejs

Прочитал, что Редис - это шустрая СУБД. Обычно в приложениях используется мускул. Я так думаю можно использовать и две СУБД. Критичные к скорости обновления данных для клиента хранить а Редис, а все остальное в мускуле. Так мона?

Вы понимаете разницу между SQL и NoSQL? Если нет, то может Вам еще рано такое делать

Не совсем. Я имел в виду веб-сервер Apache для самого сайта и nodeJS для рассылки уведомлений, они могут быть на одном физическом (виртуальном) сервере.

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

Основной смысл: у вас будут две связки:
Apache (Nginx) + MySQL + PHP — для сайта
nodeJS — система уведомлений

Обе связки подключены к Redis — быстрому хранилищу данных, которое как нельзя лучше подходит для этой цели (читайте ниже почему).

Клиент (пользователь) при загрузке страницы соединяется с nodeJS сервером (есть отличная библиотека socket.io, которая позволяет в практически любом браузере реализовать поддержку сокетов) и ждет уведомлений.

Как это работает:
в Redis есть система pub/sub — publish / subscribe. Это система событий в Redis.
Когда у вас на сайте, на стороне PHP, происходит какое-либо событие, например, пользователь отправил другому пользователю сообщение, то PHP публикует запись в Redis.
nodeJS мгновенно получает эту запись (наше уведомление) и отправляет клиенту.
Все это происходит очень и очень быстро, это не займет больше секунды, если у клиента, конечно, стабильное интернет-соединение. Это вообще произойдет быстрее, чем завершится работа PHP скрипта, т.к. запись в Redis будет отправлена во время работы скрипта, а не после его завершения.

Почему нельзя это сделать на PHP
Это можно реализовать без всяких дополнительных инструментов, используя, например, Ajax или технологию long-polling.

Ajax не особо подходит по нескольким причинам:

Проверять каждую секунду сервер неприемлемо, т.к. это создаст большую нагрузку (100 активных пользователей — 100+ запросов к серверу каждую секунду = 100+ запросов к MySQL для проверки новых уведомлений)
Это медленно. Т.к. каждую секунду проверять сервер мы не можем, нам придется устанавливать разумный интервал, например, 10 секунд. Если вы создаете систему мгновенных сообщений, это не подходит.

Теперь о long-poll.

Если кратко, то система работает так:
браузер делает запрос к серверу, который НЕ закрывается до тех пор, пока не произойдет какое-либо событие на сервере.
Пояснение:
вы открыли страницу сайта. JS код делает GET Ajax запрос к серверу, а сервер держит этот запрос открытым до тех пор, пока ему не нужно будет что-то ответить, в нашем случае — отправить уведомление. То есть: соединение держится открытым до тех пор, пока не потребуется отправить уведомление.

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


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

(Отредактировано автором: 19 Ноября, 2013 - 12:47:47)

Знаю что одна реляционная, а другая нет. А вот как это использовать с пользой пока не понял.

Я в свое время делал подобные финты и мне хватало nginx push http module.
Не надо никаких редисов, никаких нод, за публикацией следит сам nginx.

http://highload.com.ua/index.php/2010/07/21/используем-nginx-как-long-polling-comet-сервер/

-----
Шта? Репозиторий?