Гарантируется тем, что JS браузера будет каждые пару секунд долбиться в nginx (т.е. в свое персональное memcache поле) и читать от туда пачку последних сообщений. Если он не обратился туда — его проблема. Если браузер подвис и при очередном чтении в поле обнаружил пропуск данных — идет инициализация всего списка сообщений. В общем есть 2 четких стадии: инициализация при первом входе (выполняется пхп), поддержания актуальности при живом окне браузера с JS (nginx+memcache).
Если делать тоже самое на очередях, то будет так: мы кинули важное сообщение в очередь, браузер прочитал его, связь накрылась, данные не пришли (и с сервера очередей оно удалено). При повтором чтении данных уже не будет. Это небольшая проблема. А если же эти данные, но с избытком (т.е. с небольшим списком более старых сообщений) просто положить в поле мемкешу — то будет не важно, сколько раз его прочитает браузер. Они «потеряются», только если появятся более свежии данные (сообщения), вытесняющие старые. В таком подходе все четко делится на не связанные между собой компоненты проекта.
1. Самый главный аргумент, почему это не будет работать: тест скорости параллельной записи и чтения событий с php в RabbitMQ показывает дико медленные числа. Порядка 3000-5000 записей+чтений в секунду на одной мощной тачке. Поэтому все возможности ребита по обработке 200.000-800.000 сообщений в секунду из-за оверхеда в php extension полностью исчезают. Банальная очередь на Redis'е большие числа дает (но, разумеется, в ней нед подписки). Прежде, чем писать статьи и грозные комменты к статье — померьте скорость :)
Если и выбирать для пхп сервер очередей — то не RabbitMQ, а что-нибудь другое. Это слишком глючная, тормозная и не рабочая связка. И конечно ребит ничем не лучше другого софта — при избытке непрочитанных сообщений уходит в своп и жестко сыпится.
2. Я может плохо читал… но на Эрланге есть готовый веб-сервер. Там один процесс (эрланга) держит один коннект. Все велосипеды собственно придуманы и реализованы много лет назад. Используйте его. Нафига городить огород с ПХП, понять не могу?
3. Как-то однобоко описана проблема крон скриптов. У нас имеется большой пул application-серверов и такой же большой пул cron-серверов. Но не в том смысле, что вы подумали! Как устроены крон скрипты:
а) это обычные php скрипты, работающие в среднем по 10 минут
б) по факту, никаких утечек памяти в пхп нет, даже если циклом создавать и уничтожать миллиард объектов (но они могут быть, поэтому скрипты, на всякий случай, дольше 10 минут не работают)
в) все скрипты всегда запущены… например, под задачу «А» всегда запущены 5 копий одного скрипта
г) когда крон-менеджер решает, что текущий скрипт превысил 10 минут, тот завершается, мгновенно запуская свою копию (т.е. никаких ожиданий 1-59 секунд от системного crontabа нет, последний нужен только, если скрипт свалится в корку и при перезагрузке всего сервера)… разумеется, прогнозируя свое скорое завершение, скрипт перестает принимать новые данные и обрабатывает накопленные
д) cron-скрипт ничем не отличается от application-скрипта, только первый принимает события из очереди (memcacheQ / redis), а не от веб-браузера
В итоге выходит полная эмуляция демонов и прочей ненадежной фигни штатными простыми средствами с обычной логикой приложения.
4. В задачах, когда бразуер очень часто должен получать данные (чат, онлайн мессенджер) существуют модули под nginx для доступа к memcacheD и memcacheQ. Пришел AJAX запрос, nginx отправил его в свой модуль (написан на С), тот принял постом данные от браузера и отправил сообщения в очередь, одновременно в JSON виде ответил браузеру, прочитав заранее подготовленный ключ в memcacheD. Все это без пхп! Не нужно никакой мути в виде демонов и комитов. Все запросы на чтение данных («нет в ли чате новых сообщения?») приходят в браузер минуя пхп полностью! Пхп занимается лишь приемом новых текстовых сообщений от человека в чат + разбором очереди от браузера (тот отчитывается, что жив, читает сообщения и т.д. — через очередь). И разумеется фоновые крон-скрипты (по методологии выше) занимаются формированием нужных ключей в мемкеше, которые запрашиваются браузером. Например, пришло новое сообщение в чат — нужно модифицировать десяток-сотню ключей в мемкеше для всех пользователей, которые сидят в этом чате. После этого не важно — будут те ключи читаться браузером или нет. Мы их один раз сформировали и до нового текстового сообщения ничего не делаем.
Ни одного лишнего компонента не используется, кроме традиционных php-fpm, nginx, модуль к nginx, memcache.
Косяков достаточно, это проблемы не подхода, а просто того что проекту едва-едва месяц и времени на него не очень много.
Может быть ещё и без флеша сделать?
Или функции флеша без js дергать?
И сделаеть без js так, чтобы музыка не прерывалась при переходах между страницами?) (нет конечно можно фреймами, но...)
И не нужно таких категоричных высказываний, все в конце концов решает выгода.
Если работа по написанию кода для работы без js себя не окупают, то они никому не нужны.
Индексация нужна всему в вебе, у чего есть контент и нужны посетители.
www.rockbaby.ru — простой пример, мне нужна индексация сайта и совершенно не нужно чтобы это все работало без js. У сайта фишка в js & flash.
Люди на медленном канале — не мои посетители, так же как и отключающие стили и сидящие с трубок.
Статистику нагуглить все могут, а вот её осмыслить.
И ничего что общая статистика — полная лажа?)
Информационные сайты одно дело, развлекательные другое и т.д.
Это верно совсем не для всех сайтов.
Для веб-приложений например совсем неверно.
И процент людей без js имеет смысл только для сайтов с хорошей посещаемостью.
Так это сизифоф труд часто.
Пользователям отсутствие поддержки работы без js практически ненужно, но делать его придется в полном объеме для индексации.
Другой вариант, подмена кода для поисковика грозит поисковым баном.
И выбирать приходится из двух зол.
Если делать тоже самое на очередях, то будет так: мы кинули важное сообщение в очередь, браузер прочитал его, связь накрылась, данные не пришли (и с сервера очередей оно удалено). При повтором чтении данных уже не будет. Это небольшая проблема. А если же эти данные, но с избытком (т.е. с небольшим списком более старых сообщений) просто положить в поле мемкешу — то будет не важно, сколько раз его прочитает браузер. Они «потеряются», только если появятся более свежии данные (сообщения), вытесняющие старые. В таком подходе все четко делится на не связанные между собой компоненты проекта.
Если и выбирать для пхп сервер очередей — то не RabbitMQ, а что-нибудь другое. Это слишком глючная, тормозная и не рабочая связка. И конечно ребит ничем не лучше другого софта — при избытке непрочитанных сообщений уходит в своп и жестко сыпится.
2. Я может плохо читал… но на Эрланге есть готовый веб-сервер. Там один процесс (эрланга) держит один коннект. Все велосипеды собственно придуманы и реализованы много лет назад. Используйте его. Нафига городить огород с ПХП, понять не могу?
3. Как-то однобоко описана проблема крон скриптов. У нас имеется большой пул application-серверов и такой же большой пул cron-серверов. Но не в том смысле, что вы подумали! Как устроены крон скрипты:
а) это обычные php скрипты, работающие в среднем по 10 минут
б) по факту, никаких утечек памяти в пхп нет, даже если циклом создавать и уничтожать миллиард объектов (но они могут быть, поэтому скрипты, на всякий случай, дольше 10 минут не работают)
в) все скрипты всегда запущены… например, под задачу «А» всегда запущены 5 копий одного скрипта
г) когда крон-менеджер решает, что текущий скрипт превысил 10 минут, тот завершается, мгновенно запуская свою копию (т.е. никаких ожиданий 1-59 секунд от системного crontabа нет, последний нужен только, если скрипт свалится в корку и при перезагрузке всего сервера)… разумеется, прогнозируя свое скорое завершение, скрипт перестает принимать новые данные и обрабатывает накопленные
д) cron-скрипт ничем не отличается от application-скрипта, только первый принимает события из очереди (memcacheQ / redis), а не от веб-браузера
В итоге выходит полная эмуляция демонов и прочей ненадежной фигни штатными простыми средствами с обычной логикой приложения.
4. В задачах, когда бразуер очень часто должен получать данные (чат, онлайн мессенджер) существуют модули под nginx для доступа к memcacheD и memcacheQ. Пришел AJAX запрос, nginx отправил его в свой модуль (написан на С), тот принял постом данные от браузера и отправил сообщения в очередь, одновременно в JSON виде ответил браузеру, прочитав заранее подготовленный ключ в memcacheD. Все это без пхп! Не нужно никакой мути в виде демонов и комитов. Все запросы на чтение данных («нет в ли чате новых сообщения?») приходят в браузер минуя пхп полностью! Пхп занимается лишь приемом новых текстовых сообщений от человека в чат + разбором очереди от браузера (тот отчитывается, что жив, читает сообщения и т.д. — через очередь). И разумеется фоновые крон-скрипты (по методологии выше) занимаются формированием нужных ключей в мемкеше, которые запрашиваются браузером. Например, пришло новое сообщение в чат — нужно модифицировать десяток-сотню ключей в мемкеше для всех пользователей, которые сидят в этом чате. После этого не важно — будут те ключи читаться браузером или нет. Мы их один раз сформировали и до нового текстового сообщения ничего не делаем.
Ни одного лишнего компонента не используется, кроме традиционных php-fpm, nginx, модуль к nginx, memcache.
С «разностью» у нас все в порядке, а над «много» мы работаем.
Уже завтра со скоростью будет все впорядке)
Может быть ещё и без флеша сделать?
Или функции флеша без js дергать?
И сделаеть без js так, чтобы музыка не прерывалась при переходах между страницами?) (нет конечно можно фреймами, но...)
И не нужно таких категоричных высказываний, все в конце концов решает выгода.
Если работа по написанию кода для работы без js себя не окупают, то они никому не нужны.
И о, да, www.lradio.ru/online-radio/# — ведь ваша работа?
Пощелкайте по ссылочкам с пунктирным подчеркиванием с выключенным JS
www.rockbaby.ru — простой пример, мне нужна индексация сайта и совершенно не нужно чтобы это все работало без js. У сайта фишка в js & flash.
Люди на медленном канале — не мои посетители, так же как и отключающие стили и сидящие с трубок.
Статистику нагуглить все могут, а вот её осмыслить.
И ничего что общая статистика — полная лажа?)
Информационные сайты одно дело, развлекательные другое и т.д.
Для веб-приложений например совсем неверно.
И процент людей без js имеет смысл только для сайтов с хорошей посещаемостью.
Пользователям отсутствие поддержки работы без js практически ненужно, но делать его придется в полном объеме для индексации.
Другой вариант, подмена кода для поисковика грозит поисковым баном.
И выбирать приходится из двух зол.
Или может уже есть написанные библиотеки для работы с ним?