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

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

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


Вопрос -

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

person vjjj    schedule 21.02.2017    source источник


Ответы (2)


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

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

person Shobhit Puri    schedule 25.02.2017

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

  2. Нет, состояние всех пользователей обычно не реплицируется на все серверы приложений, это будет огромная трата ресурсов. Сервер аутентификации (или кластер серверов) может сам действовать как балансировщик нагрузки или перенаправлять все запросы на отдельный балансировщик нагрузки — верно для приложения без сохранения состояния.

В приложении с отслеживанием состояния отдельные серверы сохраняют состояние пользователей посредством фиксированных сеансов.

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

person vjjj    schedule 26.02.2017