2017-01-08 20 views
0

Как часть обучения распределенных систем, я создаю приложение для чата. В настоящее время мой проект заключается в том, чтобы каждый сервер знал клиентов, к которым они подключены (это состояние, которое будет реплицироваться с использованием согласованного алгоритма).Хорошая практика для отправки backend-сервера ip: порт для клиента через балансировщик нагрузки

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

ответ

0

Не знаете, почему вы использовали бы такой алгоритм, как Raft здесь. Традиционно RAFT используется для выбора лидера. Не похоже, что вам это нужно. Что-то вроде:

клиент> балансировки нагрузки (HAproxy)> пула серверов чата

HAproxy (балансировки нагрузки) может выполнять проверку работоспособности на ваш пул серверов. Если сервер умирает, он будет удален из пула. Когда сервер становится горячим/напряженным, он может «выходить из строя» проверки работоспособности, которые должны быть удалены из пула (серверы бэкэнда должны выкидывать статус http-почты 503 через проверки работоспособности). Когда трафик исчезает, сервер будет снова добавлен обратно в пул. Вы можете предупредить/контролировать количество активных членов пула чатов.

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

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