AWS LB липкость - это нечто другое, вы не можете хранить вещи в LB липкости, это контролируется сервисом, лежащим в основе AWS. Балансировщик нагрузки использует специальный файл cookie для отслеживания экземпляра для каждого запроса каждого слушателя. Когда балансировщик нагрузки получает запрос, он сначала проверяет, присутствует ли этот файл cookie в запросе. Если это так, запрос отправляется экземпляру, указанному в файле cookie. Если cookie не существует, балансировщик нагрузки выбирает экземпляр на основе существующего алгоритма балансировки нагрузки.
Вы можете использовать функцию закрепленного сеанса (также известную как привязка сеанса), которая позволяет балансировщику нагрузкипривязать сеанс пользователя к конкретному экземпляру. Это гарантирует, что все запросы от пользователя во время сеанса будут отправлены в один и тот же экземпляр.
LB липкие сеансы просто направляют последующий запрос того же экземпляра ec2 от того же пользователя, это поможет приложению, подобному WebSocket.
lb-sticky-сессий
Так что если вы ищете способ управления и храненияконфиденциальные данные и эти данные должны быть доступны на нескольких узлах, тогда вам нужно распределенное управление сеансами с использованием Redis или Memcached. если вы используете case только для того, чтобы прикрепить последующий запрос к тому же экземпляру EC2, тогда достаточно липкости LB.
Существует множество способов управления пользовательскими сеансами в веб-приложениях, от только файлов cookie до распределенныхбазы данных ключ / значение, включая локальное кэширование на сервере. Хранение данных сеанса на веб-сервере, отвечающем на данный запрос, может показаться удобным, поскольку доступ к данным не требует задержки в сети. Основным недостатком является то, что запросы должны тщательно маршрутизироваться, чтобы каждый пользователь взаимодействовал только с одним сервером и одним сервером. Другим недостатком является то, что после сбоя сервера все данные сеанса также удаляются. Распределенная база данных ключ / значение в памяти может решить обе проблемы, заплатив небольшую цену за небольшую задержку в сети. Хранение всех данных сеанса в cookie-файлах достаточно хорошо в большинстве случаев;если вы планируете хранить конфиденциальные данные, то предпочтительнее использовать сеансы на стороне сервера.
building-fast-session-caching-with-amazon -astic -ache-for-redis
