предыдущий постSpringSession: интегрировать SpringBootописывает, какSpringBootИнтеграция ДжоливудаSpringSession, весь процесс очень прост, и его также легко проанализироватьSpringSessionпринцип действия. Следуя предыдущей практике, в этой статье в основном анализируютсяSpringSessionпринцип.
1. Начните со схемы согласованности сеанса
оsessionа такжеcookieДля некоторых знаний вы можете обратиться к статье, которую я написал ранее:Поговорим о сеансах и файлах cookie.
SessionКак механизм, используемый сервером для записи состояния клиента, он прозрачен для клиента; ноSessionДля нормальной работы по-прежнему требуется поддержка клиентского браузера. мы все знаем,HTTPПротоколы не имеют состояния,Sessionне могу полагаться наHTTPсоединение, чтобы определить, является ли это одним и тем же клиентом, поэтому серверу необходимо отправить идентификационный флаг браузеру клиента (sessionId), эта опознавательная метка проходит черезCookieмеханизм до конца.
1.1. Происхождение проблемы согласованности сеансов
Когда пользователь впервые посещает нашServletКогда на стороне сервера приложений будет создан независимыйSession, и хранится в памяти. Эта ситуация может быть реализована в сценарии с одним сервером приложений (здесь не обсуждается один из его недостатков, а именно нагрузка на сервер, вызванная использованием памяти). В кластерном сценарии этот механизм будет иметь проблемы:
1.1.1. Автономная сцена
Поскольку это сервер приложений, каждый запрос пользователя обрабатывается этой машиной, поэтому не будетsessionобщая проблема.
1.1.2 Кластерный сценарий
Предположим, что сейчас в кластере три машины (сверху вниз: A->B->C). Когда текущий пользователь инициирует доступ в первый раз, запрос назначается машине А для обработки.SessionДанные записываются в память машины А, при повторной инициации доступа запрашивается выделенная обработка Б, но в это время в памяти Б нет данных текущего пользователя, поэтому естьsessionпротиворечивая ситуация.
1.2, Решение проблемы согласованности сеанса
В нынешнюю эпоху сервис-ориентированных и унифицированных приложений простыеSessionОн больше не может соответствовать нашим требованиям. Затем нам нужно найти решение для замены текущей реализации хранилища памяти на одной машине.
1.2.1 Механизм реализации на основе IP-HASH
В 1.1.2, поскольку мы не можем знать, какой машине будет назначен запрос, это приведет кsessionВозникают проблемы несоответствия. Если мы сможем решить проблему, заключающуюся в том, что каждый запрос пользователя может быть закреплен за определенной машиной, то проблемы, упомянутой выше, на самом деле не существует.IP-HASHЭто такая схема. запрашивающим клиентомIPпровестиHASHВычислите и сопоставьте результат расчета с конкретной машиной, чтобы запрос мог быть фиксированно привязан к определенной машине, таким образом эффективно избегаяsessionВозникновение проблем согласованности.
Преимущества этого подхода:
- Нет необходимости изменять какой-либо код приложения, 0 вторжений.
- Высокая безопасность, не зависит от рисков, связанных с другими сторонними системами кэширования.
- бюджетный
Но проблема также очевидна, этот метод фактически избегаетsessionПроблемы согласованности возникают не дляsessionРешение проблемы непротиворечивости. Главная проблема:
- Основываясь на памяти приложений, это окажет определенное давление на сервер приложений.
- Перезапуск службы вызовет
sessionданные потеряны - Не подходит для горизонтального масштабирования, горизонтальное масштабирование также может быть потеряно
session - Есть единая точка высокой нагрузки, то есть большинство запросов проходит через
HASHПопадите в ту же машину после расчета, пока остальные машины простаивают.
1.2.2 Репликация сеанса
Принцип реализации этого метода заключается в том, что сервер приложений создаетsessionПосле этого многоадресная рассылкаsessionотправляется на другие серверы приложений в рамках многоадресного адреса. Таким образом, по сравнению сIP-HASHСпособ стать надежнее:
- Также нет необходимости менять какой-либо бизнес-код
- Возможность адаптации к нескольким стратегиям нагрузки
- После того, как машина перезагрузится или выйдет из строя, можно не опасаться потери, потому что есть избыточные резервные копии
Но у этого подхода есть и большая проблема:
- Первый — это синхронизация между серверами
sessionОн будет занимать определенное количество сетевых ресурсов, и в то же времяsessionЕсть задержка при синхронизации между разными машинами. - Или на основе хранилища памяти, ограниченного влиянием объема памяти компьютера, плохой горизонтальной масштабируемостью.
- Память сервера должна хранить память на других машинах
sessionДанные, потребление памяти будет увеличиваться с увеличением масштаба кластера, что может привести к частым запускам машины.GC.
1.2.3 Реализовать централизованное управление сеансами с помощью трехстороннего механизма кэширования
Вышеупомянутые два метода управляются самим сервером.sessionДа, основная проблема это влияние на производительность и память. Принцип этого метода состоит в том, чтобыsessionРазмещено на стороннем программном обеспечении (например,redis) для единого управления. Этот метод может эффективно решить проблемы производительности, использования памяти и горизонтального расширения. Однако из-за внедрения стороннего программного обеспечения возрастут сложность внедрения и затраты на эксплуатацию и обслуживание.
РаспределенныйsessionБольшинство схем реализации основано на этом методе;SpringSessionне исключено.
2, Анализ функциональной структуры SpringSession
Перед распределенным сценариемSessionПроблемы согласованности описаны и решеныSessionРазбор нескольких стратегий на предмет непротиворечивости (немного грубовато, в интернете много знаний). Имея в виду этот фон, давайте посмотрим наSpringSessionпринцип реализации.
2.1 Введение
Spring SessionОбеспечивает управление информацией о сеансе пользователя.APIи реализация, что упрощает поддержку кластерных сеансов, не полагаясь на решения, специфичные для контейнера приложений. Он также обеспечивает прозрачную интеграцию:
- Разрешает контейнер приложения (
Tomcatи т. д.) нейтральный способ заменыHttpSesseion, поддерживается вheadersдоступно вsession IDsиспользоватьRESTful API. - предоставляется при получении
WebSocketпродолжайте сообщениеHTTPВозможность выживания сеанса - Позволяет производить замену нейтральным по отношению к контейнеру приложения способом.
Spring WebFluxизWebSession.
Вышеприведенный перевод документа с официального сайтаSpring Session
2.2 Модули
Spring SessionВ основном включает 4 модуля:
-
spring-session-core:при условииSpring Sessionосновной функционал иAPI -
spring-session-data-redis:кredisкак механизм храненияSessionRepositoryвыполнить -
spring-session-hazelcast:кHazelcastкак механизм храненияSessionRepositoryвыполнить -
spring-session-jdbc: реляционная база данных как механизм храненияSessionRepositoryвыполнить
В целом ядроAPI+ Реализация хранилища, скриншоты инженерных модулей следующие:
2.3 Функциональная структура
SpringSession в целом можно разделить на три части:
- Для обработки веб-уровня это включает переписывание запросов, добавление пользовательских фильтров в цепочку фильтров, обработку файлов cookie, обработку заголовков http и т. д.
- Общая базовая инкапсуляция, такая как определение абстрактного интерфейса верхнего уровня класса хранения, пользовательская конфигурация, обработка событий и т. д.
- Часть хранилища, которая на самом деле является реализацией интерфейса общедоступного базового пакета, предоставляет множество реализаций хранилища, включая Redis, хранилище в памяти, jdbc и т. д.
2.4 Поддержка нескольких сеансов
Для часто используемых распределенных сеансов реализация обычно полагается на файлы cookie. Но в весенней сессии реализована стратегия на основе заголовка для передачи jessionID. В то же время до версии 2.0.4 для того же браузера и того же веб-сайта springsession поддерживает несколькоsessionпроблема, но поддержка сеансов была прекращена после этого выпуска. Для получения дополнительной информации о поддержке нескольких сеансов см.официальная документация.
резюме
В этой статье кратко представлены несколько стратегий реализации распределенного сеанса. Для распределенных сеансов ключевым является решение проблемы согласованности.В настоящее время большинство решений, которые я видел, реализованы с помощью [централизованного управления сеансами с помощью трехсторонней структуры кэширования], включая введение в эту серию статей.
В дополнение к представлению о решении согласованности распределенного сеанса, как вторая статья SpringSession, здесь представлен краткий анализ функциональных модулей Springsession, чтобы анализ исходного кода можно было провести позже.