Плюсы и минусы стратегии Sticky Session / Session Affinity load blancing?

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

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

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

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

45
load-balancing scalability session sticky

1 ответов

плюсы:

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

плюсы:

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

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

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

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

64