Как достигается стабильность сеанса на нескольких веб-серверах?

23

Сколько веб-серверов имеет StackOverflow / ServerFault?

Если ответ «больше, чем один», то достигает ли он Session Stickiness при опросе DNS?

domain-name-system web-server p.campbell
источник
Не совсем, но если это сформулировать иначе, это может вызвать интересный вопрос.
Вы должны перефразировать вопрос. Измените заголовок на «Как достигается стабильность сеанса на нескольких веб-серверах?» или что-то в этом роде ...
Уильям Брендель
не могли бы вы сделать мне одолжение, чтобы показать мне правильную фразу?
1
Предположение о том, что наличие нескольких серверов подразумевает липкие сеансы, которые являются мерзостью, мне больно.
womble

Ответы:

42

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

Выбор метода будет зависеть от стиля балансировки нагрузки, а также от доступности / емкости внутреннего хранилища:

Информация о сеансе сохраняется только в файлах cookie : информация о сеансе (а не только идентификатор сеанса) хранится в файле cookie пользователя. Например, cookie пользователя может содержать содержимое его корзины покупок. Чтобы предотвратить вмешательство пользователей в данные сеанса, HMAC может быть предоставлен вместе с cookie. Этот метод, вероятно, наименее подходит для большинства приложений:

  • Бэкэнд-хранилище не требуется
  • Пользователю не нужно каждый раз подключаться к одной и той же машине, поэтому можно использовать балансировку нагрузки DNS.
  • Нет задержки, связанной с получением информации о сеансе с компьютера базы данных (как это предусмотрено в HTTP-запросе). Полезно, если ваш сайт сбалансирован по нагрузке машинами на разных континентах.
  • Количество данных, которые могут быть сохранены в сеансе, ограничено (ограничение размера куки 4K)
  • Необходимо использовать шифрование, если пользователь не может видеть содержимое своего сеанса.
  • HMAC (или аналогичный) должен использоваться для предотвращения вмешательства пользователя в данные сеанса
  • Поскольку данные сеанса не хранятся на стороне сервера, разработчикам сложнее отлаживать

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

  • Обработка сеанса существующего приложения, возможно, не должна быть изменена, чтобы стать осведомленной о нескольких машинах
  • Для хранения сессий не требуется система общей базы данных (или аналогичная), что может повысить надежность, но за счет сложности
  • Отключение бэкэнда завершит все запущенные на нем сеансы пользователей.
  • Вывести машины из строя сложнее. Пользователи с сеансами на машине, которые должны быть отключены для технического обслуживания, должны иметь возможность выполнять свои задачи до выключения машины. Для поддержки этого в веб-балансировщиках нагрузки может быть предусмотрена функция «утечки» запросов к определенной бэкэнд-машине.

Общая серверная база данных или хранилище ключей / значений : информация о сеансе хранится в серверной базе данных, к которой все веб-серверы имеют доступ для запроса и обновления. Браузер пользователя сохраняет cookie, содержащий идентификатор (например, идентификатор сеанса), указывающий на информацию о сеансе. Это, наверное, самый чистый метод из трех:

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

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

Tommeh
источник
2
+1 Достаточно исчерпывающий ответ и спасает меня его написание. :) Что касается хранения в базе данных, реляционная база данных, вероятно, неправильная вещь. Что-то вроде одной из постоянных вилок memcached лучше. memcachedb может подойти. Вы также пропустили репликацию информации о сеансе между серверами. Это не самый лучший метод, но такие вещи, как tomcat, делают это, поэтому стоит документировать.
Дэвид Пашли
Какой подход используется Google, Twitter или Facebook?
Дэннибой
1
Не уверен насчет Google, Twitter или Facebook, но Redis отлично подходит для магазина сессий. В основном это «постоянный memcached», который Дэвид Пашли рекомендовал в 2009 году, когда Redis был в зачаточном состоянии.
Бен Р
4

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

zombat
источник
+1 за упоминание централизованной базы данных. Просто чтобы немного расширить / упростить эту идею. Если вы установили cookie на ПК пользователя с чем-то уникальным, например, с глобальным идентификатором пользователя, вы можете сохранить этот GUID в базе данных. Не имеет значения, к какому серверу подключается клиент, если у него есть GUID / cookie, вы сможете просматривать их в базе данных и соответствующим образом отслеживать сеанс.
KPWINC
2
Хранение сессий в реляционной базе данных всегда плохая идея. Вы не должны использовать базы данных для хранения временных данных.
Дэвид Пашли
2

Использование nemcached кажется хорошим решением, о котором не упоминал @David Pashley

Это означает наличие удаленного экземпляра memcached, используемого всеми серверами, и использование расширения memcache PECL, предоставляющего собственный обработчик сеанса.

Требуется только изменить два параметра в конфигурации php!

Вот хороший учебник http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/

Тристан
источник
Но что есть несколько центров обработки данных?
Дэннибой
0

IIRC, в DotNetRocks # 440 они указали один период сервера. Не знаю, так ли это до сих пор.

Изменить: На самом деле это был Hanselminutes # 134 . Сожалею.

оборота ongle
источник
0

Вы можете установить печенье.

Вы можете вычислить хэш удаленного IP-адреса (на простейших удаленных хостах с нечетными номерами переходить на сервер A, хосты с четными номерами переходить на сервер B).

Похоже, вы также можете сделать это через некоторые значения, которые остаются с исходной системой, если вы используете туннель ssl.

Как правило, для каждого из перечисленных механизмов требуется «обратный прокси-сервер» или какой-либо балансировщик нагрузки. Этот балансировщик нагрузки принимает трафик и затем направляет его на тот сервер, на котором изначально был сеанс, на основе одного из вышеуказанных критериев.

Я не уверен, однако, что вы подразумеваете под "опрос DNS"

Крис
источник
0

а) Вы можете хранить информацию о сеансе в файле cookie пользователя. См. Защищенные файлы cookie без сохранения состояния, которые не хранят данные на стороне сервера, но сохраняют состояние сеанса http://www.cl.cam.ac.uk/~sjm217/papers/protocols08cookies.pdf . б) Вы можете изменить внутреннее хранилище сессии на базу данных или memcached. Чтобы устранить единственную точку отказа, вы можете установить репликацию базы данных или несколько узлов memcached. Обратите внимание, что memcached рекомендуется в таких установках, где потеря пользовательского состояния в сеансе не является большой ошибкой и не делает его очень несчастным. Для случаев, когда сохранение состояния жизненно важно, используйте базы данных. И PHP, и Django, и Rails позволяют разработчику создавать собственные бэкенды сессий.

Кристапу
источник