2013-07-20 2 views
0

Чтобы поддерживать состояние пользователя, веб-сервер создает объект Session и назначает его уникальному session_id. Это имеет смысл в сценарии с одним сервером. Но что происходит в распределенной архитектуре сервера, где каждый запрос может попасть на другой сервер. Как этот объект Session используется совместно с различными веб-серверами? Один из способов, я могу думать о том, чтобы хранить его в базе данных, но это было бы слишком неэффективно, поскольку каждое чтение будет иметь дополнительную задержку.Как распределенный веб-сервер поддерживает состояние клиентов

Я хочу знать, какие методы используются для решения этой проблемы?

ответ

1

Это очень зависит от архитектуры приложения и того, что не хватает информации о сеансе, которую вы хотите поделиться.

Если вы хотите использовать общий токен для аутентификации, который может быть выполнен с помощью перезаписи URL или файлов cookie.

Если вы хотите хранить большие объекты, вам необходимо будет взглянуть на свою балансированную нагрузку архитектуру (кластер) и принять решение. Конечно, я не могу explan все здесь, как это обширные темы, но я могу дать вам несколько советов из моего опыта, так что вы можете исследовать дальше:

  1. Sticky session: При таком подходе клиент застрять с одним из сбалансированных серверов нагрузки и всегда всегда обслуживается только этим сервером. Это означает, что вы управляете всеми сеансами и т. Д., Как это было бы на одном сервере узла.
  2. Cluster topology: Посмотрите на свой кластер узлов и посмотрите, какие топологии он поддерживает, и может ли он совместно использовать данные среди других. Я ранее настраивал: Ring и Star. См. Статью this для более подробной информации.
  3. Database: Это один из самых простых и классических способов совместного использования объектов в сбалансированных нагрузках.
  4. File System: Очень похоже на базу данных, можно сериализовать объекты и получить их позже, используя централизованную файловую систему, например. NFS, AFS.
Смежные вопросы