Насколько я понимаю, использование липких сеансов заключается в маршрутизации пользователя к тому же бэкэнду, чтобы им не приходилось, например, снова входить в систему каждый раз, когда они перенаправляются, или если у них есть корзина для покупок, они не будут теряют свои элементы и т. д. Но я также знаю, что лучше не сохранять состояние на внутренних серверах, и в этом случае рекомендуется сохранять сеанс в БД или в БД в памяти. Это правильно ? если да, то есть ли смысл использовать липкие сеансы, например, при хранении состояния в БД?
Обычно цель липких сессий - убедиться, что пользователь всегда направлен на один и тот же бэкэнд, при условии, что бэкэнд включен (и обычно вы хотите, чтобы пользователь перешел на любой другой бэкэнд, если он не работает!)
Имея это в виду, если бэкэнд выходит из строя, перезапускается или уходит, обновляется или имеет проблемы, ваш пользователь окажется на другом бэкэнде, поэтому, если вы храните данные сеанса только на бэкэнде, тогда пользователь теряет данные своего сеанса (должен вернуться в игру, потерять тележку и т. д.).
Таким образом, во всех случаях сеансы необходимо либо реплицировать между серверной частью (если она хранится в внутренней памяти), либо хранить в хранилище сеансов, таком как Redis, Memcached, RDBMS и т. Д. Если вы этого не сделаете, то у вас относительно низкий уровень обслуживания.
Теперь, нужен ли липкий сеанс, даже если вы храните сеанс в хранилище сеансов, внешнем по отношению к бэкэнду?
Это действительно зависит от вашей среды, архитектуры, дизайна и т. Д. Это может иметь для вас смысл, а может и не быть необходимым.
Помимо сеанса могут быть другие вещи, которые могут потребовать использования прикрепленных сеансов. Допустим, у вас есть веб-сервис, обрабатывающий файл. Пользователь загружает файл, и он обрабатывается одним из нескольких бэкэндов. После первоначальных вызовов делаются дополнительные вызовы для проверки статуса обработки файла. Запросы статуса должны поступать на серверную часть, обрабатывающую файл. В этом поможет липкая сессия. Если серверная часть умирает, обработка файла, конечно, прекращается, и следующий запрос статуса возвращает что-то вроде «ваша работа больше не существует!».
Конечно, вы также можете хранить обновления статуса в базе данных (например, Redis или другие подобные вещи), а затем запросы статуса могут отправляться на любой сервер. Но это более сложно, и усложнение не всегда оправдано.
Как правило, я бы сказал, что если у вас очень небольшая настройка, небольшая база пользователей, липкий сеанс обычно лучше, чем более сложная инфраструктура с хранилищем сеансов. Предположительно, вы будете запускать несколько бэкэндов для поддержания высокого времени безотказной работы. Так что, если у вас есть внешнее хранилище сеансов, вам также необходимо сделать это HA ... теперь сложность вашей системы увеличивается.
Вот что мне нравится в IT - как бы там ни было ...