Согласен, с RabbitMQ, пожалуй, самая популярная схема. Но у меня был ряд технических требований, по которым не желательно было использовать технологии вне стека. А RabbitMQ в нашем бэкенде отсутствует.
Инстансов запущено с запасом, деплоятся они по очереди. Т.е. берем одну машину, останавливаем старую версию приложения, поднимаем новую, и так для всех. При таком подходе одновременно переподключается только 1/N (N - кол-во инстансов) пользователей. Но в любом случае, с нашей нагрузкоймы легко перевариваем одновременный обрыв всех коннектов.
А чего такого нету в xmpp, чтобы пришлось его расширять?
Хотелось иметь RPC в протоколе.
Про бекенд, всё же, хотелось бы поподробнее послушать.
На бэкенде крутится wamp-роутер. Бизнес-логика чата является wamp-клиентом по отношению к роутеру и крутится с ним в одном процессе. При таком подходе их легко разнести на разные сервера в будущем при разрастании бизнес логики и изменении профиля нагрузки. Сообщения и чаты хранятся в репликасете монги. Для операций типа "создать новый чат", "получить список сообщений с курсорной навигацией" используется RPC подход. Для пользовательских сообщений и различных событий типа "пользователь появился в сети", "пользователь покинул чат" используется PubSub. Механизм с realm используется для разделения на проекты.
У ejabberd были в своё время проблемы в синхронизации чатов между разными инстансами в кластере. У вас такой проблемы нету? Или один толстый инстанс запущен?
Текущая инсталляция состоит из трех небольших инстансов (4 ядра / 8 ГБ). Все wamp-сообщения с кодом EVENT сервер повторяет всем членам кластера. Это позволяет общаться в одном чате пользователям, подключенным к разным серверам. При разрастании кластера до размеров, когда fan-out может стать проблемой, есть возможность шарить списки подписчиков и слать события адресно.
Какие нагрузки?
Сейчас нагрузка небольшая - до 1000 пользователей в онлайне в пике. С такой нагрузкой справляется и один инстанс. Три запущены, как говорится, на всякий случай.
Согласен, с RabbitMQ, пожалуй, самая популярная схема. Но у меня был ряд технических требований, по которым не желательно было использовать технологии вне стека. А RabbitMQ в нашем бэкенде отсутствует.
Нет, не рассматривал. Спасибо за наводку, погуглю.
Инстансов запущено с запасом, деплоятся они по очереди. Т.е. берем одну машину, останавливаем старую версию приложения, поднимаем новую, и так для всех. При таком подходе одновременно переподключается только 1/N (N - кол-во инстансов) пользователей. Но в любом случае, с нашей нагрузкоймы легко перевариваем одновременный обрыв всех коннектов.
Хотелось иметь RPC в протоколе.
На бэкенде крутится wamp-роутер. Бизнес-логика чата является wamp-клиентом по отношению к роутеру и крутится с ним в одном процессе. При таком подходе их легко разнести на разные сервера в будущем при разрастании бизнес логики и изменении профиля нагрузки. Сообщения и чаты хранятся в репликасете монги. Для операций типа "создать новый чат", "получить список сообщений с курсорной навигацией" используется RPC подход. Для пользовательских сообщений и различных событий типа "пользователь появился в сети", "пользователь покинул чат" используется PubSub. Механизм с realm используется для разделения на проекты.
Текущая инсталляция состоит из трех небольших инстансов (4 ядра / 8 ГБ). Все wamp-сообщения с кодом EVENT сервер повторяет всем членам кластера. Это позволяет общаться в одном чате пользователям, подключенным к разным серверам. При разрастании кластера до размеров, когда fan-out может стать проблемой, есть возможность шарить списки подписчиков и слать события адресно.
Сейчас нагрузка небольшая - до 1000 пользователей в онлайне в пике. С такой нагрузкой справляется и один инстанс. Три запущены, как говорится, на всякий случай.
При текущей нагрузке проблем пока не выявлено.