Плюсы:
- это просто - никаких изменений в приложении не требуется.
- лучше использует локальные кэши ОЗУ (например, просматривайте профиль пользователя один раз, кэшируйте его и можете повторно использовать при последующих посещениях того же пользователя)
Минусы:
- если сервер не работает, сеанс теряется. (обратите внимание, что это является условием хранения информации о сеансе локально на веб-сервере, а не липких сеансов как таковых). если то, что находится в сеансе, действительно важно для пользователя (например, черновик письма) или для сайта (например, корзина покупок), то потеря одного из ваших серверов может быть очень болезненной.
- , в зависимости от «липкой» реализации в вашем балансировщике нагрузки, может направлять неравную нагрузку на одни серверы по сравнению с другими
- перевод нового сервера в оперативный режим не сразу дает новому серверу большую нагрузку - если у вас есть система динамической балансировки нагрузки для борьбы с пиками, прилипание может замедлить вашу способность быстро реагировать на пики. Тем не менее, это в некоторой степени угловой случай, и на самом деле относится только к очень большим и сложным сайтам.
- если у вас относительно мало пользователей, но трафик одного пользователя может затопить один сервер (например, сложные страницы с SSL, AJAX, динамически сгенерированными изображениями, динамическим сжатием и т. Д.), То стикеры могут повредить время отклика конечного пользователя, так как вы Вы не распределяете нагрузку одного пользователя равномерно по серверам. Если у вас много одновременно работающих пользователей, это не проблема, так как все ваши серверы будут забиты!
Но если вам нужно использовать состояние сеанса на локальном сервере, липкие сеансы определенно являются подходящим способом - и даже если вы не используете состояние сеанса на локальном сервере, липкость имеет преимущества, когда дело доходит до использования кэша (см. Выше). ). Ваш балансировщик нагрузки должен иметь возможность просматривать файлы cookie HTTP (не только IP-адрес), чтобы определить привязанность, поскольку IP-адреса могут изменяться в течение одного сеанса (например, стыковка ноутбука между проводной и беспроводной сетью).
Более того, вообще не используйте состояние сеанса на веб-сервере! Если состояние сеанса очень болезненно терять (например, корзины покупок), сохраняйте его в центральной базе данных и периодически очищайте старые сеансы. Если состояние сеанса не является критическим (например, имя пользователя / URL-адрес аватара), поместите его в файл cookie - просто убедитесь, что вы не помещаете слишком много данных в файл cookie.
Современные версии Rails по умолчанию хранят переменные сеанса в cookie по вышеуказанным причинам. Другие веб-фреймворки могут иметь опцию «хранить в куки» и / или «хранить в БД».