Горизонтальное масштабирование приложения, которое разделяет входные данные между серверами

Question

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

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

Прямо сейчас у меня есть брокерский процесс, к которому подключается каждый интерфейс, затем подписываются на очередь за все, о чем могут потребоваться его связи. Это делается для вырезания сообщений от брокера, которые никогда не будут использоваться интерфейсом. Тем не менее, я все еще получаю от 75% до 85% сообщений, отправляемых обратно каждому интерфейсу от брокера.

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

Пример: если я получаю 10 сообщений на 11 интерфейсных серверах, это что-то (110 сообщений - 10 сообщений обрабатываются локально и не отправляются обратно брокером) * 0.75 оптимистичный уровень подписки = 75 сообщений, отправляемых обратно для каждого сервера. Таким образом, у нас есть 10 локальных + 75 брокеров = 85 сообщений, обрабатываемых на этот отрезок времени каждым сервером.

Теперь у меня не было бы 11 интерфейсных серверов за 100 мс/с, возможно, два, но сообщения, отправляемые обратно на каждый внешний сервер по процессу брокера, как бы взорвали больше сообщений, которые я получаю через дополнительные интерфейсные серверы.

Брокерский процесс - это небольшое приложение node.js, которое ведет переговоры с RabbitMQ и PostgreSQL. Интерфейсные серверы также являются приложениями node.js.

Что я могу делать или должен ли я делать по-другому, чтобы поддерживать латентность в периоды высокой громкости?

Обновление для ответа на комментарий пользователя: Хотя я ожидаю много перекрытия между очередями, соединение приведет к тому, что их внешний сервер будет подписаться, я не ожидаю, что он будет 100% для каждого сервера. Худший случай - каждый сервер интерфейса должен подписываться на каждую очередь на брокере, получая 100% сообщений от брокера. Оптимистично, только около 75% сообщений действительно нужно будет отправить обратно на какой-либо конкретный внешний сервер.

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

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

Answer 1

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

Я не работал с RabbitMQ, поэтому я не могу сдуть вас с деталями, но горизонтальное масштабирование означает кластер, поэтому http://www.rabbitmq.com/clustering.html может быть достаточно, чтобы вы начали.

Answer 2

Предположим, что каждый пользователь подключается только к одной комнате чата в любой момент времени. Это означало бы одно соединение с веб-разъемом = одна чат-комната. Таким образом, вы должны написать дополнительный узел.js обратный прокси, который будет перенаправлять каждое пользовательское соединение на «front-end» node.js-процесс, который, скорее всего, уже прослушивает события в этой комнате чата (сродство к чат-комнате, использующее последовательное хеширование на основе идентификатора chatroom). Этот алгоритм маршрутизации должен быть наиболее эффективным для улучшения использования сети, поэтому он не должен быть идеальным.

Теперь позвольте каждому пользователю находиться в нескольких чатах. Затем вам необходимо улучшить обратный прокси-сервер, чтобы подключиться к нескольким серверам «front-end» и мультиплексировать результаты обратно пользователю.

Эта конструкция обеспечит горизонтальную масштабируемость за счет латентности сети.

Примечание: Конечно, новый обратный прокси теперь является интерфейсным сервером, но когда я упоминаю «front-end», я обращаюсь к серверам, как вы их описали в вопросе.