Плюсы и минусы стратегии прилипания к сеансу/сеансу Affinity load blancing?

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

Одна из проблем, которую представляет этот подход, - это то, где серверы осведомлены о состоянии - сохранение состояния пользователя в "сеансе".

Одним из решений этой проблемы является "липкий сеанс" (например, "сродство сеанса" ), где каждый пользователь назначается одному серверу, а его данные состояния содержатся на этом сервере исключительно на протяжении всего сеанса.

Каковы плюсы и минусы подхода "липкой сессии"? Вы используете его, и если вы удовлетворены этим?

Ответ 1

Плюсы:

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

Минусы:

Если сервер опускается, сеанс потерян. (обратите внимание, что это сообщение о сохранении информации о сеансе локально на веб-сервере - не из липких сеансов как такового). если то, что в сеансе действительно важно для пользователя (например, проект электронной почты) или на сайте (например, в корзине покупок), потерять один из ваших серверов может быть очень болезненным.
в зависимости от "липкой" реализации в вашем балансировщике нагрузки, может направить неравную нагрузку на некоторые серверы и другие.
приносящий новый сервер в сети, не сразу дает новый сервер большой нагрузки - если у вас есть динамическая система балансировки нагрузки для обработки всплесков, липкость может замедлить вашу способность быстро реагировать на всплеск. Тем не менее, это несколько угловой случай и действительно относится только к очень крупным и сложным сайтам.
Если у вас относительно мало пользователей, но один пользовательский трафик может загружать один сервер (например, сложные страницы с SSL, AJAX, динамически генерируемые изображения, динамическое сжатие и т.д.), тогда листы могут повредить время отклика конечных пользователей, так как вы "не равномерно распределяет нагрузку на одного пользователя на всех серверах. Если у вас много одновременных пользователей, это не проблема, так как все ваши серверы будут загружены!

Но если вы должны использовать состояние локального сеанса сервера, то липкие сеансы определенно подходят для вас - и даже если вы не используете локальное состояние сеанса на сервере, липкость имеет преимущества, когда дело доходит до использования кеша (см. выше). Ваш балансировщик должен иметь возможность просматривать HTTP файлы cookie (а не только IP-адрес), чтобы определить липкость, поскольку IP-адреса могут меняться в течение одного сеанса (например, стыковка ноутбука между проводной и беспроводной сетью).

Даже лучше, не используйте состояние сеанса на веб-сервере вообще! Если состояние сеанса очень болезненно, чтобы потерять (например, тележки для покупок), храните его в центральной базе данных и периодически очищайте старые сеансы. Если состояние сеанса не является критическим (например, имя пользователя/URL-адрес аватара), затем вставьте его в файл cookie - просто убедитесь, что вы не перетаскиваете слишком много данных в файл cookie.

Современные версии Rails по умолчанию хранят переменные сеанса в файле cookie по вышеуказанным причинам. Другие веб-фреймворки могут иметь опцию "хранить в cookie" и/или "хранить в DB".