Как управлять переменными сеанса в веб-кластере?

Question

Переменные сессии обычно хранятся в оперативной памяти веб-сервера.

В кластере каждый запрос, сделанный клиентом, может обрабатываться другим узлом кластера. не так ли?!

Итак, в данном случае ...

• Что происходит с переменными сеанса? Разве они не хранятся в оперативной памяти узлов?
• Как другие узлы будут правильно обрабатывать мой запрос, если в нем нет моих переменных сеанса или, по крайней мере, всех?
• Эта проблема решается веб-сервером (Apache, IIS) или языковой средой выполнения (PHP, ASP.NET, Ruby, JSP)?

РЕДАКТИРОВАТЬ: Есть ли какое-то решение для Classic ASP ?

Answer 1

Расширять ответ @ yogman.

Memcached - это просто потрясающе! Это высокопроизводительный и распределенный кэш объектов.

И хотя я упоминал о распределении, это в основном так же просто, как запуск одного экземпляра на одном из ваших запасных / незанятых серверов, вы настраиваете его как в ip, порту и сколько оперативной памяти использовать, и все готово.

memcached -d -u www -m 2048 -l 10.0.0.8 -p 11211

(Запускает memcached в режиме демона для пользователя www, 2048 МБ (2 ГБ) ОЗУ на IP 10.0.0.8 с портом 11211.)

С этого момента вы запрашиваете в memcached данные, и если данные еще не кэшированы, вы извлекаете их из исходного источника и сохраняете их в memcached. Я уверен, что вы знакомы с основами кэша.

В кластерной среде вы можете связать свои memcached'ы в кластер и реплицировать кеш через ваши узлы. Memcached работает в Linux, Unix и Windows, запускайте его везде, где у вас есть свободное ОЗУ, и начинайте использовать свои ресурсы.

API для memcached должны быть общедоступными . Я говорю следует , потому что я знаю только Perl, Java и PHP. Но я уверен, что, например, в Python у людей есть способы использовать это также. Существует memcached wiki , на случай, если вам нужны указатели, или дайте мне знать в комментариях, если я бредил слишком много. ;)

Answer 2

Существует 3 способа сохранения состояния сеанса в ASP.NET. Первый находится в процессе, где переменные хранятся в памяти. Второе - использовать службу состояния сеанса, добавив в файл web.config следующее:

<sessionState
    mode="StateServer"
    stateConnectionString="tcpip=127.0.0.1:42424"
    sqlConnectionString="data source=127.0.0.1;user id=sa;password="
    cookieless="false"
    timeout="20" />

Как видно из атрибута stateConnectionString, служба состояния сеанса может находиться на другом компьютере.

Третий вариант - использовать централизованную базу данных SQL. Для этого вы помещаете в файл web.config следующее:

<sessionState
    mode="SQLServer"
    stateConnectionString="tcpip=127.0.0.1:42424"
    sqlConnectionString=
     "data source=SERVERHAME;user id=sa;password="
    cookieless="false"
    timeout="20"
/>

Более подробно обо всех этих опциях написано здесь: http://www.ondotnet.com/pub/a/dotnet/2003/03/24/sessionstate.html

Answer 3

Получите Linux-машину и настройте http://www.danga.com/memcached. Его скорость непобедима по сравнению с другими подходами. (например, куки, формы скрытых переменных, базы данных)

Answer 4

С Hazelcast вы можете использовать распределенную карту Hazelcast для хранения и совместного использования сеансов в кластере или позволить Hazelcast Webapp Manager сделать все за вас. Пожалуйста, проверьте документы для деталей. Hazelcast - это распределенное / многораздельное, легкое и простое бесплатное решение для распространения данных для Java.

С уважением,

-talip

http://www.hazelcast.com

Answer 5

Как и все виды вещей, «это зависит».

Существуют разные решения и подходы.

Как уже упоминалось, существует концепция централизованного хранилища для состояния сеанса (база данных, memcached, общая файловая система и т. Д.).

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

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

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

В этот момент клиент вполне может быть прикреплен к новой машине.

Разные платформы делают это по-разному, включая отсутствие состояния сеанса вообще.

Answer 6

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

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

На каждой последующей странице, где вам нужны данные сеанса, запрашивайте таблицу сеансов с уникальным идентификатором, переданным в строке запроса.

Пример:

Считайте, что ваш сайт имеет 4 страницы: Login.asp, welcome.asp, taskList.asp, newtask.asp

Когда пользователь входит в систему, используя страницу login.asp, после проверки пользователя создайте запись в таблице сеансов и сохраните требуемые значения для конкретного сеанса (скажем, дата входа пользователя) / время для этого примера). Получите уникальный идентификатор новой записи сеанса (допустим, уникальный идентификатор abcd ).

Добавьте все ссылки на вашем сайте с уникальным идентификатором, как показано ниже:

• welcome.asp? SESSIONID = ABCD
• tasklist.asp? SESSIONID = ABCD
• newtask.asp? SESSIONID = ABCD

Теперь, если на какой-либо из указанных выше веб-страниц вы хотите отобразить дату / время входа пользователя в систему, вам просто нужно запросить таблицу сеансов с параметром sessionID ( abcd в этом случае) и отображается для пользователя.

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

Надеюсь, это поможет.

Answer 7

Как сказал Уилл, большинство подходов с балансировкой нагрузки будут использовать своего рода залипание при распределении предстоящих запросов от одного и того же клиента, а это означает, что уникальный клиент попадет на тот же сервер, если этот реальный сервер не выйдет из строя.

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

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

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

Answer 8

В ASP.NET вы можете сохранить данные сеанса в базе данных SQL Server, которая является общей для всех веб-серверов в кластере.

После настройки (в файле web.config для вашего сайта) платформа обрабатывает все данные для вас, и вы можете получить доступ к данным сеанса в обычном режиме.