пользователя в большом (высоком трафике) применение

Question

Предположения -

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

Вопрос -

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

Answer 1

1. в безгосударственной системе с несколькими серверов, отдельный сервер (сервер аутентификации) или отдельный кластер серверов (аутентификация API) удерживает состояние всех пользователей. Если это один сервер аутентификации для большого приложения, вы можете ожидать, что он будет иметь ОЗУ в пределах 100-х ГБ, а может и больше.
   
   
2. Нет, состояние всех пользователей обычно не реплицируется на всех серверах приложений, это будет огромная трата ресурсов. Сервер аутентификации (или кластер серверов) может действовать как сам балансировщик нагрузки или перенаправлять все запросы на отдельный балансировщик нагрузки - true для приложения без состояния.
   
   

В отслеживании состояния приложения, отдельные сервера держать состояние пользователей через липкие сессии.

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

Answer 2

Вы можете использовать липкие сеансы. Он позволяет балансировщику нагрузки привязывать сеанс пользователя к определенному экземпляру. Это гарантирует, что все запросы пользователя во время сеанса будут отправлены в один и тот же экземпляр. Читайте Sticky and NON-Sticky sessions.

Также предположим, что экземпляр убит по какой-то причине, чтобы поддерживать состояние, токен аутентификации и другая информация также могут быть сохранены в отдельном кеш-кеке redis, который намного быстрее запрашивается. Read Session Management in microservices