В общем, что думаете о такой реализации кластеров websockets? Внутри

IMDB ассоциативный массив, где ключ это id юзера, а второе это список ws, где он прямо сейчас подключён(С компа, с мобилки например).

1. Отправитель отправляет сообщение получателю. 2. ws инстанс кидает запрос в IMDB на этого пользователя. 3. Получает ответ в виде списка id юзера в каждом конкретном ws и id каждого конкретного ws. 4. ws инстанс кидает ответ получателю, который подключен к нему, если есть такой. 5. Отправляет в Kafka остальные элементы из списка, если есть. Тут так же может быть IPC, если инстансы ws находятся на одном сервере. 6. Kafka кидает сообщение другому инстансу ws. 7. Отпавляет получателю сообщение.

В общем, давайте оценку моей идеи.

https://tugdualgrall.blogspot.com/2015/01/how-to-create-pubsub-application-with.html Я всё больше склоняюсь юзать IMDB монги. Попросту мне нужна будет абстракция "комнат", а в случае таком я смогу их организовать в базе данных, создав коллекцию и ссылки на юзеров. В Redis я так не смогу. Pub/sub тут организовать можно. А ещё MongoDB оказывается могёт в много поток, а Redis не.

В общем, плохая идея. Kafka стабильная, держит нагрузки, но медленная. Если бы можно было поставить что-то вместо неё..

Ну, медленная относительно Redis конечно. Так-то быстрая.

А сколько времени отрабатывает?

Точно не скажу. Дело в самой реализации. У Kafka очередь, а у Redis pub/sub это "кинуть и забыть".

В общем, Kafka это для общения между сервисами, а не между инстансов WebSockets например. Kafka пойдёт, когда у тебя зарегался пользователь и ему нужно отправить письмо. Тогда веб сервер кидает сообщение в Kafka и другой сервис подхватывает это, кидает письмо.

Ещё описать это можно как разные инструменты. Для грязи пойдут гусеницы, а не колёса.

Спасибо за разъяснение, а то скоро будем в проекте кафку вводить

Ахахахха.. Из меня не очень архитектор приложений. Kafka крута, но для целей, что я описал - Связь между разными сервисами. Расскажешь, что за проект?

Ну много микросервисов, как раз для их общения и будем использовать (щас общение по http))

Спрашивала о том, повлияла ли Кафка на скорость отработки, так как важна скорость в нашей ситуации

Блыа. Больно. Хотя.. А HTTP/1.1 или 2.0?

А фиг знает, только щас узнала о разных версиях

Крутыа.. А о чём проект в целом-то?

Если только узнала, то скорее всего 1.1.

Кол центр

ip-телефония?

Ну да, только я работаю над интеграцией с ней

Хих.. Интересненько.

Кстати, было интересно почитать о твоих возможных реализациях, спасибо)

Хмсь. Если интересно, то пиши задачу в лс.

А как ты сравнил скорость, и насколько медленнее? Возможно, kafka тут действительно слишком мощный инструмент, и хватит nanomsg (zeromq) или nats?

Так. Сек.

Как я уже сказал, дело в том, как внутри работает Kafka. Я уже приводил сравнение. Я попросту выбрал не тот инструмент. За nanomsg, zeromsg и nats спасибо. Это уже похоже на то, что мне нужно.

Так. Мне бы их ещё все сравнить между собой...

зачем? я бы предположил, что производительности кафки тебе тоже хватило бы, вроде никто не жалуется но если так хочется именно дешёвых решений - я бы предположил что nanomsg будет быстрее других, которые я упомянул

Дешёвых?

по ресурсам судя по твоему описанию ты испугался кафки потому что там много чего происходит "под капотом"

Я уже сказал, что дело в способе работы.

Ну я так понял, что тебе просто не нужны навороты Кафки Или что-то другое в ней не устраивает?

Просто очередь сообщений не то, что мне нужно. А как держит нагрузки nanomsg и какая задержка? У меня выходит запрос в БД + передача в этот транспорт. Мне нужно меньше 200мс при передаче фоток весом до 2мб, когда фотка уже была получена с клиента и меньше 50мс при передачи текстовых сообщений до 2к символов.

Хорошо держит 🤷‍♂ Конкретно под твои запросы надо разворачивать стенд и на нём проверять Он достаточно тонкую прослойку представляет из себя, думаю быстрее него сложно написать что-то со схожей функциональностью. Единственное, доки у него скудные, и мне приходилось в исходники лезть чтобы с чем-то разобраться. С этой точки зрения zeromq лучше - проект того же автора, но достаточно старый для того, чтобы и доков было много, и комьюнити более развитое, и статей/примеров хватало

Я пытался найди на nanomsg найти как скелить его. Нинашёл.

А да, проблема в том, что оно должно держать по-настоящему огромные нагрузки. Типо 100к сообщений в минуту.

В минуту? Это не огромные тогда, а скорее средние

Угу. Потянет? Вообще, это не должен быть лимит. Вдруг ещё нужно будет.

Потянет