Масштабируемое push-приложение с node.js

Question

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

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

Вот пример дизайна крупномасштабного приложения для чата:

1 - Серверы имеют состояние, они поддерживают открытые соединения, и клиенты могут получать новые сообщения на них. В этом сценарии мы ограничены физической памятью одного сервера, поэтому мы не можем масштабировать линейно, если у нас слишком много пользователей на комнату.

2 - Серверы не имеют состояния, они запрашивают распределенную базу данных для ответа на запросы клиентов. В этом случае клиенты опрашивают серверы. Мы могли бы масштабировать линейно, но пропускная способность уменьшается, сообщения не доставляются мгновенно, а опрос масштабируется как плохая практика при масштабировании.

3 - сочетание 1 и 2. Серверы поддерживают открытые соединения своих клиентов и опрашивают распределенную базу данных. Приложение более сложное для написания, и мы все еще используем опрос. Подобные клиентские запросы (клиенты из одной комнаты) просто группируются в один, выполняемый сервером. Код становится излишне сложным и не масштабируется в ситуации, когда у нас много комнат и несколько пользователей на комнату.

4 - Серверы не имеют состояния, и кластер базы данных использует событие для уведомления всех зарегистрированных серверов о новых сообщениях. Это решение, которое я хотел бы иметь, но я не слышал ни о какой базе данных, имеющей эту функцию. (Некоторые люди говорят об этой функции для mongodb здесь: https://jira.mongodb.org/browse/SERVER-124)

Так почему 4-е решение сегодня так мало используется?

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

Answer 1

Поскольку вам нужно приложение push, вы, вероятно, будете использовать Socket.IO с RedisStore.

При использовании этой комбинации данные для всех соединений сохраняются в Redis (вбаза данных), так что вы можете масштабировать вне процесса.Другое использование Redis здесь для pub-sub.

Идея состоит в том, чтобы вызвать событие, когда нужно что-то нажать, а затем отправить сообщение в браузер с помощью Socket.io.Если вы хотите прослушать изменения базы данных, возможно, лучше использовать CouchDB с функцией _changes .

Ресурсы:

https://github.com/dshaw/talks/tree/master/2011-10-jsclub/sample-apphttp://www.ranu.com.ar/2011/11/redisstore-and-rooms-with-socketio.html Как повторно использовать подключение redis в socket.io?

Answer 2

Вместо триггеров для случая 4 вы можете подключиться к репликации MongoDB.

Предположим, у вас есть набор реплик (вы не запускаете один mongod, не так ли?).

Каждое изменение записывается в oplog на первичном сервере и затем реплицируется на вторичные.

Вы можете эффективно извлекать новые обновления из оплога, используя настраиваемые курсоры . Обратите внимание, что это все еще тянуть, а не толкать.

Тогда ваш node.js отправит эти события клиентам.