Комментарии 31
Вы не поверите, у меня все еще весьма благополучно работает realplexor Дмитрия Котерова, написанный на Perl. Ем и нахваливаю) Принцип там тот же.
Конечно, в мире достаточно подобных проектов, более матерых и закаленных большим количеством инсталляций внутри живых проектов. Однако я вижу ценность Центрифуги в нескольких вещах. Она написана на Python на основе современных библиотек — Tornado, SockJS. Это достаточно популярные технологии и, возможно, некоторые python-программисты смогут найти решение своих проблем в коде Центрифуги, даже не используя ее по прямому назначению, — достаточно много подводных камней пришлось преодолеть на пути к тому виду, что есть сейчас. Также Центрифуга обладает некоторыми отличиями от большинства существующих решений — это уникальный механизм настроек каналов, приватные каналы для пользователей, авторизация, веб-интерфейс из коробки да и много еще чего можно назвать — так что, мне кажется, проект получился достаточно самобытным. На мой взгляд — ее действительно очень легко использовать, тем более если вы — питонист.
Я в заключении к статье старался подчеркнуть, что я никоим образом не призываю всех подсаживаться на Центрифугу — тем более если вы уже используете нечто подобное.
Я в заключении к статье старался подчеркнуть, что я никоим образом не призываю всех подсаживаться на Центрифугу — тем более если вы уже используете нечто подобное.
Хотя мы тоже используем реалплексор в продакшине уже года четыре, но вот согласится, что это одно и то же, очень сложно. Все же, там только long-polling, а здесь Websocket если есть (а все же, в большинстве случаев он есть). Кроме того, в реалплексоре есть все еще сложные баги с размером сообщений (но поддается конфигурированию, хоть не очевидному). Так что в этих двух продуктах больше разного, чем общего, хотя в основе лежит базовая архитектура сообщений с бекенда в браузер.
Я, скорее, для ностальгии. Меня радует, но и пугает то обстоятельство, что мы используем настолько старую гвардию)
Вашу разработку всячески приветствую и, наряду с прочими, буду рассматривать как будущую альтернативу.
Вашу разработку всячески приветствую и, наряду с прочими, буду рассматривать как будущую альтернативу.
Автор изобрел велосипед Publish/Subscribe?
Подружить все это с AngularJS (или любой другой библиотекой с 2-way data binding) и сделать Q-совместимым — и настанет в мире счастье.
Они дружат) У меня сформировалась целая библиотека для увязки angular с комет-сервером. Причем на уровне прямого взаимодействия с апи там — минимум, сам без проблем переключал на разные технологии или даже на очередь ajax-запросов на lowload проектах, где это было оправдано. Если найдутся, кому интересно, выложу и опишу (может, новая политика Хабра простимулирует начать писать, наконец)
Как вы боретесь с лимитом открытых соединений в браузере пользователя? Допустим пользователь открывает несколько табов и начиная с некоторого таба в нем пропадают нотификации т.к. браузер не дает открыть новое соединение к хосту с центрифугой (исчерпан лимит открытых соединений).
У вебсокетов нет таких проблем — пользователь может открывать сколько угодно вкладок. Я так понимаю, что в спецификации вебсокетов нет четко озвученного лимита на количество открытых соединений — и в различных браузерах эти лимиты возможно есть и отличаются — но число все равно очень большое. В случае если браузер не поддерживает вебсокеты — Центрифуга с этим никак не борется — это уже оставлено на участь разработчиков конкретного сайта. В интранете Mail.Ru Group раньше использовался SSE (Server-Sent Events) для подобных вещей — и мы перешли на использование Центрифуги (а вместе с ней и вебсокетов) отчасти потому, что столкнулись с жалобами пользователей, у которых странички подвисали при загрузке.
это решается, в общем случае, DNS-балансировкой (по моим тестам — достаточно одной строки конфигурации домена и одной строки клиентского кода).
Вообще, стандартное (и самое распространенное) решение этой проблемы – сделать CNAME запись в DNS вида *.comet.example.com, которая будет указывать на comet.example.com. После этого на кленте, при открытие новой вкладки, вы просто рандомно генерите адрес для comet вида blablabla.comet.example.com.
Но это все прошлый век.
Самое грамотное решение следующее:
Браузер может спокойно конектится к тому же домену что и страница, но делать это должна только одна вкладка из всех открытых. Технически делается так – с помощью html5 localStorage табы браузера голосуют между собой и выбирают лидера, который начинает так же через localStorage сообщать всем «жив, работаю и т.д.». Этот лидер уже и общается непосредственно с сервером и мультиплексирует сообщения для других табов (опять же через localStorage).
Благодаря этому мы снижаем нагрузку на сервер на порядки. В прямом смысле слова – на порядки. В старом варианте, если юзер откроет 10 табов, то все они будут общаться с сервером. В случае с мультиплексированием – только один таб.
Минус один – мы отрезаем все браузеры, ниже IE8 (все, кто без localStorage). Ну и фиг с ними…
P.S.: Саму идею этого решения я услышал на конфе несколько лет назад от одного из разработчиков ВКонтакте. Никакой готовой либы в те времена я не нашел и стал стругать собственный костыль. Оказалось все не так уж и страшно. Вышло где-то строк 50.
Так что… ройте лучше в эту сторону.
Но это все прошлый век.
Самое грамотное решение следующее:
Браузер может спокойно конектится к тому же домену что и страница, но делать это должна только одна вкладка из всех открытых. Технически делается так – с помощью html5 localStorage табы браузера голосуют между собой и выбирают лидера, который начинает так же через localStorage сообщать всем «жив, работаю и т.д.». Этот лидер уже и общается непосредственно с сервером и мультиплексирует сообщения для других табов (опять же через localStorage).
Благодаря этому мы снижаем нагрузку на сервер на порядки. В прямом смысле слова – на порядки. В старом варианте, если юзер откроет 10 табов, то все они будут общаться с сервером. В случае с мультиплексированием – только один таб.
Минус один – мы отрезаем все браузеры, ниже IE8 (все, кто без localStorage). Ну и фиг с ними…
P.S.: Саму идею этого решения я услышал на конфе несколько лет назад от одного из разработчиков ВКонтакте. Никакой готовой либы в те времена я не нашел и стал стругать собственный костыль. Оказалось все не так уж и страшно. Вышло где-то строк 50.
Так что… ройте лучше в эту сторону.
Спасибо, я бы даже сказал большое спасибо, пощупаем. А Redis вообще рулит.
А чем вызвана смена лицензии?
Класс! Приятно видеть, что проект развивается!
Вы не думали подготовить докер контейнер с центрифугой?
Как думаете, будет ли плюсом, если центрифуга была бы написана не на питоне, а на эрланге?
Вы не думали подготовить докер контейнер с центрифугой?
Как думаете, будет ли плюсом, если центрифуга была бы написана не на питоне, а на эрланге?
Спасибо за добрые слова!
Докер-контейнер было бы неплохо сделать — вот открыл issue, теперь не забуду
Я с самого начала разработки считал, что Erlang был бы идеальным языком для подобного сервера. Но на выходе у Python есть большой плюс — понятный для большого числа программистов (а самое главное для меня самого) код, что немаловажно для open-source проекта.
Докер-контейнер было бы неплохо сделать — вот открыл issue, теперь не забуду
Я с самого начала разработки считал, что Erlang был бы идеальным языком для подобного сервера. Но на выходе у Python есть большой плюс — понятный для большого числа программистов (а самое главное для меня самого) код, что немаловажно для open-source проекта.
Я думаю главной фишкой эрланга была бы независимость от внешнего хранилища при работе в кластере — работа в кластере заложена в отп.
Кстати, у вас центрифуга работает сингл нодой или кучей через редис?
Кстати, у вас центрифуга работает сингл нодой или кучей через редис?
Да, согласен, архитектура была бы на голову выше. Я часто сетую, что несколько раз брался за Erlang, восхищаясь насколько хорош он для распределенных приложений, но… чуть отойдешь от чистой передачи данных по сети — и вот уже проблемы — с юникодом беда, с библиотеками беда — меня это останавливало, тем более после Python. Может все это не правда, или уже не правда — так как я все-таки далек от Эрланга… Что вы думаете по этому поводу?
Я возможно не совсем понял вопрос — как в интранете Mail.Ru работает Центрифуга? Если так — то у нас одна нода без Редиса — хватает с головой пока что. Максимально одновременно было около 1.5 тыс. соединений. Немного — но больше из корпоративного портала не выжмешь:) Но если станет не хватать — подключим Redis.
Я возможно не совсем понял вопрос — как в интранете Mail.Ru работает Центрифуга? Если так — то у нас одна нода без Редиса — хватает с головой пока что. Максимально одновременно было около 1.5 тыс. соединений. Немного — но больше из корпоративного портала не выжмешь:) Но если станет не хватать — подключим Redis.
У меня на SockJS + Tornado (но без центрифуги) порядка 2-3к пользователей постоянно в онлайне, ожидается прибавление ещё 6к пользователей на этой неделе.
Посматриваю в сторону pub/sub, в основном, для отказоустойчивости.
Можете описать, как у вас устроена работа с pub/sub?
Я пока думаю о том, чтобы просто сделать общую шину на Redis.
Посматриваю в сторону pub/sub, в основном, для отказоустойчивости.
Можете описать, как у вас устроена работа с pub/sub?
Я пока думаю о том, чтобы просто сделать общую шину на Redis.
Ну да, в Центрифуге просто общая Redis-шина и есть
Ок, понял.
Меня беспокоит только то, что тогда на 200к сообщений в секунду узким местом станет Redis, ведь у pypy+tornado+sockjs тот же лимит 200к сообщений в секунду.
У меня пока сообщений в среднем очень мало, но уж если готовиться к масштабированию, то серьёзно.
Меня беспокоит только то, что тогда на 200к сообщений в секунду узким местом станет Redis, ведь у pypy+tornado+sockjs тот же лимит 200к сообщений в секунду.
У меня пока сообщений в среднем очень мало, но уж если готовиться к масштабированию, то серьёзно.
Ну да, к сожалению, это так — так или иначе при таком подходе узким местом является центральный PUB/SUB прокси. Изначально в Центрифуге был ZeroMQ PUB/SUB — можно было запустить несколько нод в brokerless архитектуре — но при этом добавлять новые ноды было очень проблематично — нужно было указывать явно адреса других нод — по-хорошему, надо было бы реализовывать алгоритм поиска и включения новых нод. Плюс проблема с общим состоянием — нужно было бы имплементировать что-то вроде Clustered Hashmap Protocol, например. Так что Redis — это решение достаточно быстрое и простое.
ООО, некоторые вещи после ОО языков (я рубист) в эрланге выносят мозг. Да, есть куча неудобств которые решаются копанием. С юникодом проблем не испытвал. Я в свое время написал бекенд для pusher на эрланге (erlypusher). Сделал основной функционал (публичные и приватные каналы), почти доделал презенс каналы и понял, что надо все переписывать (тяжело строить хорошую архитектуру в функциональном языке без опыта). Потом наткнулся на elixir и понял, что переписывать надо будет именно на нем. Из-за синтаксического сахара эликсир сильно приятнее эрланга.
Значит вы сделали редис наперед. Я в ерлипушере начал с мультинодовости, но когда делал презенс каналы не разобрался как настроить мнезию на нескольких нодах и сделал однонодовым.
Кмк, сейчас гораздо важнее иметь удобный докер контейнер, чем мультинодовость
Значит вы сделали редис наперед. Я в ерлипушере начал с мультинодовости, но когда делал презенс каналы не разобрался как настроить мнезию на нескольких нодах и сделал однонодовым.
Кмк, сейчас гораздо важнее иметь удобный докер контейнер, чем мультинодовость
Кстати, докер-контейнер, как оказалось , уже использовался для Центрифуги программистом из ЮАР:) Ох уж этот open-source!
Можно ещё посмотреть crossbar.io — wamp.ws роутер на Python.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Centrifuge — я больше не буду обновлять страницу перед отправкой комментария