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

Сколько веб-серверов у StackOverflow / ServerFault?

Если ответ «более одного», то достигается ли Прилипчивость сеанса при опросе DNS?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я не совсем понимаю, что вы имеете в виду под "опросом DNS".

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