Чат на основе Erlang (распределение нагрузки и распределение нагрузки)

Question

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

1) Идея:

Nginx - перенаправляет запрос на случайный узел (круговой) -> Erlang кластера - перенаправляет к фактическому узлу (мы выбираем узел с минимальным количеством процессов) -> Рукопожатие -> Перейдите на WebSocket.

Каждый узел в кластере имеет таблицу ETS, которая содержит количество процессов для каждого узла (поля - узел, num_processes). Каждый узел каждые 5 секунд отправляет свое количество процессов всем узлам кластера.

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

2) Дополнительный вопрос:

Это хорошая идея, чтобы зарегистрировать активные соединения WebSocket пользователя (PID) по всему миру с gproc? Нам нужен этот список для каждого пользователя для отправки уведомлений через ws для конечного пользователя.

Answer 1

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

2) Вы можете использовать свойство gproc named {Username, true} для каждого процесса веб-рассылки - это позволит вам найти все сеансы websocket для пользователя по всему кластеру.

Я забыл, какой базовый протокол gproc используется для глобальных регистраций, и какие затраты вы будете иметь для регистрации/отмены регистрации свойств в течение всего кластера. Я работал над очень подобной системой (присутствие пользователя и обмен сообщениями с сеансами и балансировка нагрузки нескольких узлов) некоторое время назад и закончил писать ngproc, чтобы поддерживать дешевый поиск имени с разрешением конфликта после разделов. Он доступен как открытый источник и может предоставить некоторые идеи, которые вы можете использовать.

Answer 2

Интересно:

• Какие количества пользователей вы проектирования для?
• Сколько данных будет отправлено в чате? Это для текста, изображений или видео?
• Что вы балансируете на нагрузку, т. Е. Какой ресурс вы ожидаете быть критическим?
• Что вы ожидаете, если узел погибнет?