Как строилась связка между сессией клиента в браузере и Redis

Что проверяют

Понимаете ли вы, зачем сессию выносят из памяти приложения и как запрос браузера находит свои данные в Redis. Следом обычно спрашивают про безопасность куки, время жизни сессии и что будет после деплоя с изменёнными классами.

Как отвечать

Начните с причины: при нескольких инстансах за балансировщиком сессия в памяти Tomcat привязывает пользователя к узлу (sticky sessions) и теряется при рестарте. Внешнее хранилище делает инстансы взаимозаменяемыми.

Цепочка в Spring:

• Spring Session: зависимость spring-session-data-redis. Spring Boot настраивает её автоматически, вручную включается через @EnableRedisHttpSession;
• фильтр: SessionRepositoryFilter оборачивает HttpServletRequest, и код работает с обычным HttpSession, не зная про Redis;
• кука: браузер хранит только идентификатор. По умолчанию кука называется SESSION, а не JSESSIONID, ставится с HttpOnly и SameSite=Lax, а Secure добавляется, если запрос пришёл по HTTPS;
• хранение: сессия лежит хэшем под ключом вида spring:session:sessions:<id>, атрибуты отдельными полями, истечение через TTL по maxInactiveInterval, который продлевается при обращении;
• сериализация: по умолчанию JDK-сериализация, её часто меняют на JSON, объявив бин springSessionDefaultRedisSerializer.

Если нужно найти все сессии пользователя (выход со всех устройств, лимит сессий), берут RedisIndexedSessionRepository, он же публикует события истечения. Альтернатива: stateless-аутентификация на JWT, где Redis нужен разве что для отзыва токенов.

Безопасность: после входа идентификатор меняется (Spring Security делает это по умолчанию и так защищает от фиксации сессии), а в саму сессию кладут минимум данных.

Где спотыкаются

Пишут своё хранилище с ручной кукой через new Cookie(...) без HttpOnly и Secure. Это изобретение Spring Session заново, только с дырами.

Кладут в сессию крупные объекты с JDK-сериализацией. После деплоя с изменённым классом старые сессии не десериализуются, и пользователей массово разлогинивает.

Не думают о недоступности Redis. Вход и все авторизованные запросы зависят от него, и без реплик и таймаутов это единая точка отказа.