вообще поставить ejabberd и не кулупать себе моск он и websocket может и пуллинг

а зачем ему понимать что пользователю они пришли?

просто в следующий раз пользователь запросить сообщения начиная от id последнего принятого

@rostel так себе совет )

вот 4 года юзаем и хоть бы хны)

ну, это конечно верно, но это как советовать поставить хадуп для хранения пары гигабайт логов

а зачем ему понимать что пользователю они пришли?

Речь идет о мнгновенных сообщениях

ну они не могут быть мгновеннее того момента, чем клиент их запросит

у сообщения есть адресат

можно в качестве очереди заюзать что-то хипстерское ) https://nats.io/

То есть в любом случае на масштабируемой архитектуре все упрется в делэй между запросами?

ну да, суммируем все раунд трипы

но они всё равно будут меньше чем время запроса от клиента к тебе в дата центр

Так смысл что-то накручивать, если можно просто бомбить сервера каждую секунду?

Можешь переформулировать вопрос?

Есть ли смысл посылать клиентом каждую секунду запрос за новыми сообдениями?

нет, ответ должен придти от сервера в вебсокет или лонг полл соединение

Тогда я не совсем понимаю. Я знаю как реализовать real-time ответы с сервера при условии, что вся кухня происходит только на одном сервере, тогда существует только один broadcast канал.

Я не понимаю как смасштабировать это решение горизонтально

я выше скидывал очередь сообщений

ты можешь писать в канал пользователя и читать из него

пишешь ты из тех серверов, куда подключены контакты, которые отправляют сообщения пользователю

читаешь ты с сервера куда у тебя подключен юзер по вебсокету

Понял, спасибо. Извини, что сразу не дошло, раньше не работал с MQ. Посоветуешь с чего можно в этой сфере начать?

И какая разница между http://nats.io/ и Rabbit MQ?

а никто не знает :)

рэббит на эрланге написан, а натс я так понимаю на го)

А с чего начать проще будет?

разница в гарантиях

наши инженеры rabbitmq вспоминают как самое ужасное что с ними было в давние времена

наши инженеры rabbitmq вспоминают как самое ужасное что с ними было в давние времена

ого, настолько рэббит плох?

говорят да

начиная с каких-то масштабов

наверное для простого чата он вполне себе пойдёт )

zeroMQ для высокочастотного трейдинга используется

zeroMQ кажется уже пованивает и разлагается

но я не спец )

а если глянуть сторону  kafka? просто читал что она хороша на больших объмах данных

пишешь ты из тех серверов, куда подключены контакты, которые отправляют сообщения пользователю

а правильно ли я понял что на каждый чат(например чат между двумя пользователями или между многими) создается своя очередь?

Как я понял - на каждого пользователя

Kafka это не совсем очередь, это распределённое хранилище логов. Разница в том, что она хранит данные пока не выйдет время, а не пока их кто-то не прочитает.

NATS (без NATS Streaming) хранит все данные в памяти, там нет диска

Rabbit MQ у нас тоже разваливался :(

Kafka это не совсем очередь, это распределённое хранилище логов. Разница в том, что она хранит данные пока не выйдет время, а не пока их кто-то не прочитает.

спасибо, вот это момента про кафку не знал. А можешь плиз чуть подробнее про рэббит рассказать почему разваливается?

А с чего начать проще будет?

Как ни странно – Redis. Это тоже не очередь, но очередь с PUB/SUB там есть. И знание Redis’а пригодится.

> А можешь плиз чуть подробнее про рэббит рассказать почему разваливается? Думаю, потому, что его сложно готовить

редис - без отказоустойчивости

Redis Sentinel, Redis Cluster – уже всё есть

Как ни странно – Redis. Это тоже не очередь, но очередь с PUB/SUB там есть. И знание Redis’а пригодится.

То есть на каждого пользователя открывать pub/sub?

Нет

Один SUB на процесс, который получает обновления

https://redis.io/topics/pubsub

То есть все писать в один канал и на каждом сервере принимать все сообщения и если у конкретного сервера есть подлючение с клиентом - отвечать?

Создание большого количества каналов приводит к дополнительной нагрузке?

Конечно, создание чего-то приводит к нагрузке. Вопрос только к какой :)

Вроде, к небольшой. Можно использовать несколько каналов, можно один. Попробуйте и так, и так.

То есть как проще, нагрузить Redis большим количеством каналов или сервера большим количеством входящих сообщений

Напишите benchmark :)

Это труднее, чем все это завести)

Тем не менее, спасибо за помощь

не за что

Aleksey, возможно это то что вам нужно - https://github.com/centrifugal/centrifugo

Aleksey, возможно это то что вам нужно - https://github.com/centrifugal/centrifugo

А горизонтальная масштабируемость там есть по умолчанию?

А горизонтальная масштабируемость там есть по умолчанию?

Да есть

Но не по умолчанию )

Да я читал, через Redix =) Я тоже самое собираюсь накрутить, только поверх своего сервера

Через redis

Лично я сам писал такой сервер, на node.js. И могу сказать что лучше взять готовый

Тем более что это от mail.ru

Хотя для кого то это контраргумент

А в чем была сложность?

Менеджмент сессий пользователя

Не то чтоб сложность, но не очевидны некоторые вши были по началу

Лично я сам писал такой сервер, на node.js. И могу сказать что лучше взять готовый

Можешь скинуть ссылку, если исходники открыты?

Можешь скинуть ссылку, если исходники открыты?

Это закрытый проект

Тем более что это от mail.ru

а у тебя был опыт работы с центрифугой? любопытная штука, присматривался к ней. интересно как она в продакшене себя ведет

а у тебя был опыт работы с центрифугой? любопытная штука, присматривался к ней. интересно как она в продакшене себя ведет

Нет, с ней не было опыта. Но проект и правда интересный, понятную задачу решает.

Возможно даже автор в этом чате есть

Теперь есть:)

Мы используем Центрифугу в 4х проектах, но нагрузка во всех небольшая к сожалению, DeviantArt выкатывал на 50тыс пользователей онлайн - 2 машинки на amazon c3, с тех пор было достаточно много оптимизаций внутри