Как масштабировать Node.js WebSocket Redis Server?

Question

Я пишу чат-сервер для Acani, и у меня есть несколько вопросов о Scaling node.js и веб-сокетах с масштабируемостью балансировки нагрузки.

1. Что именно означает балансировка нагрузки Node.js? Означает ли это, что будет запущено n независимых версий моего серверного приложения, каждая на отдельном сервере?

2. Чтобы разрешить одному клиенту передавать сообщение всем остальным, я храню набор всех webSocketConnections открыт на сервере. Но если у меня запущено n независимых версий моего серверного приложения, каждое на отдельном сервере, то у меня будет n разных наборов webSocketConnections?

3. Если ответы на 1 и 2 положительные, то как мне сохранить универсальный набор webSocketConnections (на всех серверах)? Один из способов сделать это - использовать Redis Pub/Sub и просто webSocketConnection подписаться на канал на Redis.

4. Но не станет ли узким местом единственный сервер Redis? Как бы мне тогда масштабировать Redis? Что это значит для масштабирования Redis? Означает ли это, что у меня есть m независимых версий Redis, работающих на разных серверах? Это вообще возможно?

5. Я слышал, что Redis не масштабируется. Почему кто-то сказал это. Что это значит? Если это правда, есть ли лучшее решение для публикации / подписки и / или хранения списка всех передаваемых сообщений?

Примечание. Если ваш ответ таков, что Акани никогда не придется масштабировать, даже если каждый из всех семи миллиардов людей (и растет) на Земле будет каждую секунду транслировать сообщение всем остальным на Земле, пожалуйста, дайте правильное объяснение.

Answer 1

Ну, несколько ответов на ваш вопрос:

1. Чтобы сбалансировать нагрузку Node.js, это означает именно то, что вы подумали о том, что это такое, за исключением того, что вам на самом деле не нужен отдельный сервер, вы можете запустить более одного процесса сервера вашего узла на одной машине.

2. Каждый сервер / процесс вашего узла будет иметь свои собственные соединения, хранилищем веб-сокетов по умолчанию (например, Socket.IO) является MemoryStore, это означает, что все соединения будут храниться в памяти машины, это необходимо для работы с RedisStore для того, чтобы работать с Redis в качестве хранилища соединений.

3. Redis PUB / SUB - хороший способ решить эту задачу

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

5. Redis не масштабируется, это правильно, но согласно этой презентации вы можете видеть, что разработка кластера является приоритетной задачей в Redis, а Redis действительно имеет кластер, но он еще не стабилен: (взято с http: // redis. IO / скачать)

Где Redis Cluster?

Разработка Redis в настоящее время сосредоточена на Redis 2.6, которая предоставит вам поддержку сценариев Lua и многих других улучшений. Это наш текущий приоритет, однако нестабильная ветвь уже содержит большинство основных частей Redis Cluster. После выпуска версии 2.6 мы сосредоточимся на превращении текущей альфа-версии Redis Cluster в бета-продукт, который пользователи могут начать серьезно тестировать. Сложно делать прогнозы, так как мы выпустим Redis Cluster как стабильный только тогда, когда почувствуем, что он надежен и полезен для наших клиентов, но мы надеемся получить разумную бета-версию на лето 2012 года и выпустить первый стабильный выпуск до конец 2012 года.

Смотрите презентацию здесь: http://redis.io/presentation/Redis_Cluster.pdf

Answer 2

2) Использование Redis может не работать для хранения соединений: Redis может хранить данные в строковом формате, и если объект подключения имеет циклические ссылки (например, Engine.IO), вы не сможете их сериализовать.

3) Создание нового клиента Redis для каждого клиента не может быть хорошим подходом, поэтому избегайте этой ловушки, если можете

Подумайте об использовании библиотеки узлов ZMQ, чтобы процессы взаимодействовали друг с другом через TCP (или IPC, если они кластеризованы как в master-worker)