Pull to refresh
Comments 11
«Картинка для привлечения внимания» вызвала очень противоречивые чувства, наверно я уже слишком не молод
И в картинке 4 неотправленных сообщения, а не 4 непрочитанных
(с) общество зануд

Зависит от восприятия. Можно понимать как немецкий почтальон докладывает, что у вас 4 непрочитанных сообщения. Развенулся спиной, и показал почтовый ящик

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


На мой взгляд эффективнее все же вести таблицу связей uid->nodeId в том же редис, где nodeId это уникальный ид ноды который генерится при запуске, нода подписывается на канал со своим id. При отправке сообщения очень просто достается nodeId используя uid, отправляется на конкретный канал ноды и это сообщение получает только та нода на которой подключен пользователь.


В заключении, хотелось бы заметить, что вы решаете проблему которая давно и довольно неплохо решена разработчиками редиса. redis cluster даст вам любую масштабируемость и отказоустойчивость которая вам нужна

На мой взгляд эффективнее все же вести таблицу связей uid->nodeId в том же редис, где nodeId это уникальный ид ноды который генерится при запуске, нода подписывается на канал со своим id. При отправке сообщения очень просто достается nodeId используя uid, отправляется на конкретный канал ноды и это сообщение получает только та нода на которой подключен пользователь.


В таком случае тут редис не нужен вовсе, либо брать rabbitmq если нужны очереди и прочие фишки, либо вариант где все ноды коннектятся друг-к-другу на прямую. И они оба рассматривались.

redis cluster даст вам любую масштабируемость и отказоустойчивость которая вам нужна


Это тоже рассматривалось.

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


Да, ноды с большой вероятностью сделают как минимум по одной подписке на каждый инстанс редиса. Но смотри: подписки эти одноименны идентификаторам пользователя, а значит сообщение Васе придет только тем нодам, которые подписались на канал конкретно Васи. Т е пока а не подпишусь на Васю, я не получу сообщения касающееся его. В данном случае условная таблица «userId->nodeId» находится, можно сказать, прямо в самом редисе, ибо подписки в нем хранятся в примерно таком же виде: «channel->clientConnection» (ну или наоборот, не суть важно). Таким образом нам не нужно плодить лишнюю сущность в виде отдельной таблицы, не тратим время на обращение к ней, а просто напрямую пользуемся самими свойствами редиса.

Либо я что-то не понял, либо внимательнее перечитайте все)
Картинка в начале текста, видимо, неспроста?
Автор немножко буратино. А может я ошибаюсь, может шайзе на всю душу.
Ку)
Изначальная суть картинки в комическом сравнении текущих технологий и старых способов коммуникации, не более того.
Тут и картинок, и кода предостаточно. +99 к наглядности)
Можно сказать что да,
любая статья в конце концов должна приходить к какому-то завершению, и в данном случае им является шардинг
Only those users with full accounts are able to leave comments. Log in, please.