Redis и Spring Boot: Полное руководство по интеграции

1. Введение в Redis и начальная настройка проекта Spring Boot

Введение в Redis и начальная настройка проекта Spring Boot

Добро пожаловать на курс Redis и Spring Boot: Полное руководство по интеграции. Это первая статья нашего цикла, в которой мы заложим фундамент для создания высокопроизводительных приложений. Мы разберем, что такое Redis, почему он так популярен в экосистеме Java, и создадим наше первое приложение на Spring Boot, которое умеет сохранять и читать данные из этого хранилища.

Что такое Redis и зачем он нужен?

Redis (Remote Dictionary Server) — это не просто база данных. Это высокопроизводительное хранилище структур данных, работающее в оперативной памяти (in-memory). В отличие от традиционных реляционных баз данных (таких как PostgreSQL или MySQL), которые хранят данные на жестком диске, Redis держит все свои данные в RAM.

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

!Сравнение скорости доступа к данным на диске и в оперативной памяти

Основные сценарии использования

В мире Spring Boot Redis чаще всего используется для следующих задач:

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

Управление сессиями. Хранение пользовательских сессий в распределенных системах.

Очереди сообщений. Использование механизмов Pub/Sub (издатель-подписчик).

Счетчики и рейтинги. Благодаря атомарным операциям инкремента.

Математика производительности

Одной из ключевых особенностей Redis является предсказуемая производительность. Большинство операций с одиночными ключами (чтение, запись) имеют временную сложность:

Где: * — время выполнения операции. * — константная сложность алгоритма (время выполнения не зависит от количества данных в базе).

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

Подготовка окружения

Перед тем как писать код на Java, нам нужно запустить сам сервер Redis. Самый простой и современный способ сделать это — использовать Docker.

Если у вас установлен Docker, выполните следующую команду в терминале:

Разберем параметры: * --name my-redis: имя контейнера. * -p 6379:6379: проброс порта. 6379 — это стандартный порт Redis. * -d: запуск в фоновом режиме (detached mode). * redis: имя официального образа.

Теперь у вас есть работающий сервер Redis, готовый принимать соединения.

Создание проекта Spring Boot

Для работы с Redis в экосистеме Spring существует мощный проект Spring Data Redis. Он предоставляет высокоуровневые абстракции, которые избавляют нас от необходимости работать с низкоуровневыми драйверами напрямую.

Шаг 1: Зависимости

Создайте новый проект (например, через Spring Initializr) и добавьте в файл pom.xml следующую зависимость. Это стартер, который подтянет все необходимые библиотеки, включая драйвер Lettuce (клиент Redis по умолчанию в Spring Boot).

Также, для удобства, нам понадобится spring-boot-starter-web, если мы захотим делать REST-контроллеры в будущем, но для базового примера достаточно и консольного приложения.

Шаг 2: Конфигурация

Spring Boot славится своей автоконфигурацией. Если ваш Redis запущен локально на стандартном порту 6379, Spring Boot найдет его автоматически без единой строчки настроек.

Однако, для наглядности и контроля, мы пропишем настройки в файле src/main/resources/application.properties:

Работа с данными: RedisTemplate

Центральным классом для взаимодействия с Redis в Spring является RedisTemplate. Это потокобезопасный класс, который берет на себя сериализацию объектов и управление соединениями.

Однако для начала мы будем использовать его упрощенную версию — StringRedisTemplate. Он предназначен специально для работы со строками, где и ключи, и значения являются обычными строками (String). Это идеально подходит для знакомства.

!Иерархия классов шаблонов для работы с Redis в Spring Data

Практический пример

Давайте напишем простой компонент, который при запуске приложения запишет данные в Redis, а затем прочитает их.

Создайте класс RedisDemoRunner:

Разбор кода

StringRedisTemplate: Мы внедрили этот бин. Spring Boot создал его автоматически.

opsForValue(): Redis поддерживает разные типы данных (списки, множества, хеши). Метод opsForValue() предоставляет интерфейс для работы с простейшим типом — строками (Key-Value).

.set(key, value): Аналог команды Redis SET.

.get(key): Аналог команды Redis GET.

Запуск и проверка

Запустите ваше Spring Boot приложение (метод main в основном классе). В консоли вы должны увидеть:

Если вы хотите убедиться, что данные действительно в Redis, вы можете зайти внутрь контейнера Docker и проверить это через утилиту redis-cli:

Примечание: Вы можете увидеть странные символы вместо кириллицы в redis-cli, это нормально и связано с кодировкой терминала, но само приложение Java будет считывать корректную строку.

Резюме

В этой вводной статье мы:

Узнали, что Redis — это сверхбыстрое in-memory хранилище.

Запустили Redis с помощью Docker.

Подключили spring-boot-starter-data-redis.

Написали первый код с использованием StringRedisTemplate для записи и чтения строк.

В следующей статье мы углубимся в работу с более сложными типами данных и разберем, как хранить полноценные Java-объекты (POJO), а не только строки.

2. Конфигурация подключения и основы работы с RedisTemplate

Конфигурация подключения и основы работы с RedisTemplate

В предыдущей статье мы успешно запустили Redis в Docker-контейнере и написали простейшее приложение, которое умеет сохранять и читать строки. Однако реальные корпоративные приложения редко ограничиваются строками и стандартными настройками. Нам нужно уметь управлять пулами соединений, настраивать таймауты и, самое главное, сохранять сложные Java-объекты в удобном формате.

В этой статье мы глубоко погрузимся в конфигурацию RedisTemplate — основного инструмента Spring Data Redis, и научимся адаптировать его под нужды высоконагруженных систем.

Архитектура подключения: Lettuce vs Jedis

Spring Data Redis поддерживает несколько драйверов для работы с Redis. Исторически двумя самыми популярными были Jedis и Lettuce.

Начиная со Spring Boot 2.0, драйвером по умолчанию является Lettuce. Почему произошел этот переход?

* Jedis: Простой, легковесный, но блокирующий (synchronous). Для работы в многопоточной среде каждому потоку требуется свое соединение с Redis. Это приводит к быстрому исчерпанию ресурсов при высокой нагрузке. * Lettuce: Построен на базе Netty. Он поддерживает асинхронную и неблокирующую модель ввода-вывода. Одно соединение может эффективно обслуживать множество потоков одновременно (thread-safe).

!Разница в управлении соединениями между блокирующим Jedis и неблокирующим Lettuce

Мы будем использовать Lettuce, так как это стандарт индустрии для Spring Boot приложений.

Продвинутая конфигурация через application.properties

В первой статье мы указали только хост и порт. Для продакшн-среды этого недостаточно. Нам необходимо настроить пул соединений (Connection Pool).

Хотя Lettuce и позволяет использовать одно соединение, пул все равно полезен для выполнения транзакций или блокирующих операций (например, BLPOP).

Добавьте следующие настройки в ваш application.properties:

Математика пула соединений

Как выбрать правильный размер пула (max-active)? Многие новички ставят огромные значения (например, 100), думая, что это ускорит работу. Это ошибка. Redis — однопоточный сервер (в основном), и слишком большое количество соединений лишь увеличит накладные расходы на переключение контекста.

Оптимальный размер пула часто можно оценить по формуле:

Где: * — оптимальное количество соединений (размер пула). * — количество ядер процессора, доступных приложению. * — время ожидания (Wait time), когда поток ждет ответа от сети или БД. * — время обслуживания (Service time), когда процессор активно обрабатывает данные.

Для I/O-интенсивных задач (какими являются запросы к Redis) отношение может быть высоким, но для Lettuce, благодаря его неблокирующей природе, часто достаточно значений в диапазоне от 8 до 16 даже для высоконагруженных систем.

Проблема сериализации

По умолчанию Spring Boot создает бин RedisTemplate<Object, Object>, который использует JdkSerializationRedisSerializer.

Если вы попробуете сохранить объект Java с настройками по умолчанию, а затем посмотрите в Redis через консоль (redis-cli), вы увидите нечитаемый набор байтов:

Это происходит потому, что стандартная сериализация Java превращает объекты в бинарный формат. У этого подхода есть минусы:

Нечитаемость: Невозможно прочитать данные глазами или изменить их вручную.

Привязка к Java: Другие микросервисы (на Python, Go, Node.js) не смогут прочитать эти данные.

Объем: Бинарный формат Java часто занимает больше места, чем JSON.

Решение — использовать JSON в качестве формата хранения.

Настройка собственного RedisTemplate

Чтобы изменить способ сериализации, нам нужно переопределить бин RedisTemplate. Создадим класс конфигурации.

Создайте пакет config и класс RedisConfig:

Разбор конфигурации

@Configuration: Говорит Spring, что в этом классе есть настройки бинов.

RedisConnectionFactory: Внедряется автоматически (на основе настроек в application.properties).

StringRedisSerializer: Используется для ключей. Ключ user:100 в Redis будет выглядеть именно как user:100.

GenericJackson2JsonRedisSerializer: Мощный сериализатор, который добавляет в JSON специальное поле @class, указывающее на тип Java-класса. Это позволяет десериализовать объект обратно без явного указания типа.

!Преобразование Java-объекта в JSON формат для хранения в Redis

Практика: Сохранение объектов

Давайте проверим нашу конфигурацию. Создадим простой класс пользователя.

Шаг 1: Модель данных

Шаг 2: Сервис для работы с Redis

Теперь используем наш настроенный RedisTemplate.

Шаг 3: Запуск

Обновим наш CommandLineRunner из прошлой статьи, чтобы протестировать новый функционал:

После запуска приложения, если вы проверите ключ в redis-cli, вы увидите красивый JSON:

Интерфейсы операций RedisTemplate

RedisTemplate предоставляет доступ к различным структурам данных Redis через специальные методы-фабрики. Вот основные из них:

Пример использования списка:

Заключение

Мы сделали огромный шаг вперед. Теперь наше приложение:

Использует Lettuce с настроенным пулом соединений для высокой производительности.

Умеет сериализовать Java-объекты в JSON, что делает данные читаемыми и переносимыми.

Готово к работе с различными типами данных Redis через соответствующие операции opsFor....

В следующей статье мы разберем паттерн Repository в Spring Data Redis, который позволит работать с Redis так же просто, как с базой данных через JPA, используя аннотации @RedisHash и интерфейсы репозиториев.

3. Хранение данных с использованием Spring Data Redis Repositories

Хранение данных с использованием Spring Data Redis Repositories

В предыдущих статьях мы научились подключаться к Redis и использовать RedisTemplate для выполнения низкоуровневых операций. Мы вручную сериализовали объекты, формировали ключи и управляли типами данных. Это мощный подход, дающий полный контроль, но он требует написания большого количества шаблонного кода (boilerplate code).

В этой статье мы поднимемся на уровень выше и рассмотрим Spring Data Redis Repositories. Этот механизм позволяет работать с Redis так же просто, как мы привыкли работать с SQL-базами данных через JPA (Hibernate), используя сущности, аннотации и интерфейсы репозиториев.

Что такое Redis Repositories?

Redis Repositories — это абстракция над RedisTemplate, которая позволяет отображать Java-объекты (Entities) на структуры данных Redis (в основном Hashes) и автоматически генерировать код для CRUD-операций (Create, Read, Update, Delete).

Если RedisTemplate — это «ручная коробка передач», где вы сами решаете, когда переключать скорость и как работать сцеплением, то Repositories — это «автомат»: вы просто жмете на педаль газа (вызываете метод save), а Spring сам решает, как именно сохранить данные в хранилище.

!Уровни абстракции в Spring Data Redis: от кода приложения до базы данных

Ключевые преимущества

Скорость разработки. Не нужно писать реализацию методов save, findById, delete. Они предоставляются из коробки.

Декларативные запросы. Можно создавать методы поиска просто по их имени, например, findByEmail(String email).

Управление индексами. Spring Data автоматически создает и поддерживает вторичные индексы для поиска по полям объекта.

Настройка проекта

Для начала работы нам не нужно добавлять новые зависимости в pom.xml, если у вас уже подключен spring-boot-starter-data-redis. Однако нам необходимо включить механизм репозиториев в конфигурации.

Добавьте аннотацию @EnableRedisRepositories в ваш конфигурационный класс:

Создание сущности (Entity)

В реляционных базах данных мы используем аннотацию @Entity. В Redis для этого используется аннотация @RedisHash. Она указывает, что объекты этого класса будут храниться в Redis в виде структуры Hash.

Создадим класс Customer:

Разбор аннотаций

@RedisHash("customers"): Эта аннотация выполняет две функции. Во-первых, она помечает класс как сущность для Redis. Во-вторых, она задает префикс для ключей. Все объекты этого класса будут храниться с ключами вида customers:ID.

@Id: Указывает поле, которое является уникальным идентификатором. Если поле строковое и пустое при сохранении, Spring автоматически сгенерирует UUID.

@Indexed: Это критически важная аннотация. По умолчанию Redis — это Key-Value хранилище, и искать можно только по ключу (id). Аннотация @Indexed говорит Spring Data создать вспомогательные структуры данных, чтобы мы могли искать пользователей по firstName.

Создание репозитория

Теперь создадим интерфейс, который будет управлять нашими сущностями. Он должен наследовать CrudRepository или PagingAndSortingRepository.

Этого достаточно! Нам не нужно писать реализацию этого интерфейса. Spring создаст прокси-объект во время выполнения приложения.

Как это работает внутри Redis?

Это самый важный раздел для понимания. «Магия» Spring Data часто скрывает детали, которые могут привести к проблемам с производительностью, если их не понимать. Давайте посмотрим, что именно происходит в Redis, когда мы сохраняем объект.

Допустим, мы выполняем код:

Spring Data Redis выполнит не одну команду, а несколько. Внутри Redis появятся следующие записи:

1. Основные данные (Hash)

Объект сохраняется в структуру Hash с ключом customers:100.

2. Главный набор ключей (Set)

Spring поддерживает множество (Set), содержащее ID всех сохраненных сущностей этого типа. Это нужно для работы метода repository.findAll().

3. Вторичные индексы (Set)

Так как поле firstName помечено аннотацией @Indexed, Spring создает специальный Set для каждого уникального значения этого поля.

Теперь, когда вы вызываете findByFirstName("Ivan"), Spring делает следующее:

Идет в Set customers:firstName:Ivan.

Получает оттуда все ID (в нашем случае "100").

Делает HGETALL customers:100 для каждого найденного ID.

Собирает объекты и возвращает List<Customer>.

Математика индексов

Использование индексов влияет на потребление памяти и скорость записи. Оценим сложность операции вставки.

Пусть: * — количество полей в объекте. * — количество полей, помеченных @Indexed.

Временная сложность вставки (Insert Time Complexity) будет:

Где: * — время на запись самого объекта (Hash). * — время на обновление вспомогательных множеств (Sets) для каждого индекса.

Это означает, что чем больше у вас индексов, тем медленнее будет операция записи (save), так как Redis нужно обновить больше структур данных. Однако чтение по этим полям становится очень быстрым — практически для поиска списка ID.

Жизненный цикл данных (TTL)

Одной из киллер-фич Redis является возможность задавать время жизни данных. В репозиториях это делается двумя способами.

Способ 1: Аннотация @TimeToLive

Вы можете добавить поле в сущность, которое будет отвечать за срок жизни в секундах.

Способ 2: Параметр аннотации @RedisHash

Если срок жизни фиксирован для всех объектов этого типа:

Важный нюанс: Когда истекает TTL основного ключа (customers:100), Redis удаляет его автоматически. Однако вспомогательные индексы (Sets, например customers:firstName:Ivan) не удаляются автоматически самим Redis, так как у них нет TTL.

Spring Data Redis решает эту проблему через механизм Keyspace Notifications. Приложение подписывается на события удаления ключей в Redis и, получая сигнал об удалении основного объекта, программно удаляет «фантомные» записи из индексов. Для этого в Redis должна быть включена настройка notify-keyspace-events.

Практический пример использования

Давайте соберем все вместе в сервисе.

RedisTemplate vs Repositories: Что выбрать?

Используйте Repositories, когда вам нужно хранить объекты с возможностью поиска по полям, и вы хотите быстро получить результат.

Используйте RedisTemplate, когда вы реализуете специфические паттерны (например, Rate Limiter на основе INCR), работаете с битовыми картами (Bitmaps) или вам нужна максимальная оптимизация хранения.

Заключение

В этой статье мы рассмотрели Spring Data Redis Repositories — мощный инструмент для работы с Redis как с объектным хранилищем. Мы узнали:

Как использовать аннотацию @RedisHash для маппинга объектов.

Зачем нужна аннотация @Indexed и как она создает вторичные индексы.

Как работает «магия» под капотом и какие структуры данных создаются в Redis.

Как управлять временем жизни объектов через @TimeToLive.

В следующей статье мы перейдем к одной из самых популярных задач для Redis — кешированию данных с использованием абстракции Spring Cache.

4. Реализация кэширования данных с помощью аннотаций Spring Cache

Реализация кэширования данных с помощью аннотаций Spring Cache

В предыдущих статьях мы прошли путь от ручного управления соединениями через RedisTemplate до использования высокоуровневых репозиториев Spring Data. Мы научились сохранять и извлекать объекты, но одна из самых частых причин внедрения Redis в архитектуру — это кэширование.

Кэширование позволяет временно сохранять результаты тяжелых вычислений или запросов к базе данных в быстрой памяти (Redis), чтобы при повторных запросах отдавать их мгновенно. Spring Boot предоставляет элегантную абстракцию для этого, позволяя добавить кэширование буквально одной аннотацией, не меняя логику самого метода.

В этой статье мы разберем, как работает Spring Cache Abstraction, настроим RedisCacheManager и изучим аннотации @Cacheable, @CachePut и @CacheEvict.

Что такое Spring Cache Abstraction?

Spring Framework не реализует кэширование сам по себе. Вместо этого он предоставляет интерфейс (абстракцию), который говорит: «Я хочу сохранить это значение по такому-то ключу». А вот как и где это сохранить — решает конкретная реализация (Provider).

В нашем случае провайдером будет Redis. Когда вы ставите аннотацию над методом, Spring создает прокси-объект, который перехватывает вызов метода, проверяет наличие данных в Redis и, если они там есть, возвращает их, не выполняя код метода.

!Схема работы прокси-механизма Spring Cache при обработке запроса

Настройка проекта

Чтобы активировать кэширование, нам нужно выполнить два шага.

Шаг 1: Включение кэширования

Добавьте аннотацию @EnableCaching в любой конфигурационный класс вашего приложения (обычно в основной класс с методом main или в отдельный CacheConfig).

Шаг 2: Настройка RedisCacheManager

По умолчанию Spring Boot настроит кэш с бесконечным временем жизни (TTL). В реальных системах это опасно: память Redis может переполниться устаревшими данными. Нам нужно настроить время жизни записей и формат сериализации (JSON вместо бинарного Java-формата).

Дополним наш класс RedisConfig из предыдущих уроков:

Теперь все данные, попадающие в кэш, будут жить 10 минут и храниться в читаемом JSON-формате.

Основные аннотации

Рассмотрим сервис, который получает информацию о продукте. Предположим, что метод getProductById выполняется долго (например, делает сложный SQL-запрос).

@Cacheable

Это самая популярная аннотация. Она выполняет логику «проверь кэш, если нет — выполни метод и сохрани».

Параметры: * value (или cacheNames): Имя кэша. В Redis это будет префикс ключа (например, products::123). * key: Ключ записи. Используется язык выражений SpEL (Spring Expression Language). #id означает «взять значение аргумента id».

При первом вызове getProductById("1") пользователь будет ждать 3 секунды. При втором вызове ответ придет мгновенно.

@CachePut

Иногда нам нужно обновить данные в кэше, даже если они там уже есть. Например, когда мы сохраняем или обновляем сущность в БД.

Аннотация @CachePut гарантирует, что метод будет выполнен, а его результат — записан в кэш.

Если не использовать @CachePut при обновлении, в кэше останутся старые данные, и пользователи будут видеть устаревшую информацию до истечения TTL.

@CacheEvict

Эта аннотация удаляет данные из кэша. Используется при удалении сущностей.

Также можно очистить весь кэш целиком, например, по расписанию:

Математика эффективности кэширования

Эффективность внедрения Redis можно оценить математически. Основная метрика — это среднее время отклика системы.

Пусть: * — время чтения из кэша (Redis), обычно < 1 мс. * — время выполнения запроса к базе данных (медленно). * — коэффициент попадания в кэш (Hit Ratio), число от 0 до 1.

Формула среднего времени выполнения запроса выглядит так:

Где: * — среднее время обработки запроса. * — вероятность того, что данные найдутся в кэше. * — вероятность того, что придется идти в базу данных (Cache Miss). * — знак умножения.

Пример: Если запрос к БД занимает 500 мс (), чтение из Redis занимает 1 мс (), и мы попадаем в кэш в 90% случаев (), то:

Мы ускорили среднее время отклика почти в 10 раз (с 500 мс до 50.9 мс)!

Условное кэширование

Не всегда нужно кэшировать всё подряд. Spring позволяет задавать условия.

condition: Применяется до выполнения метода. Если условие ложно, кэширование отключается (работает как обычный метод).

unless: Применяется после выполнения метода. Если условие истинно, результат не кэшируется.

Распространенные ошибки (Pitfalls)

Проблема самовызова (Self-invocation)

Кэширование в Spring работает через Proxy. Когда вы вызываете метод из другого класса, вызов проходит через прокси, и магия срабатывает. Но если вы вызовете кэшируемый метод из того же самого класса, прокси будет проигнорирован.

Решение: Вызывать метод из другого бина или использовать AopContext.currentProxy() (требует дополнительной настройки), либо перепроектировать архитектуру.

Ключи кэша

Если вы не укажете key, Spring сгенерирует его на основе всех параметров метода. Если параметры — сложные объекты, убедитесь, что у них корректно реализованы методы hashCode() и equals(). Лучшая практика — явно указывать ключ через SpEL, например key = "#user.id".

Заключение

Использование аннотаций Spring Cache с Redis позволяет значительно ускорить приложение с минимальными усилиями. Мы:

Подключили @EnableCaching.

Настроили RedisCacheManager с JSON-сериализацией и TTL.

Разобрали аннотации @Cacheable, @CachePut, @CacheEvict.

Научились оценивать выгоду от кэширования математически.

В следующей статье мы рассмотрим более сложные сценарии: как реализовать распределенные блокировки (Distributed Locks) с помощью Redis, чтобы синхронизировать действия между несколькими экземплярами микросервисов.

5. Продвинутые темы: Pub/Sub, TTL и настройка сериализации

Продвинутые темы: Pub/Sub, TTL и настройка сериализации

Добро пожаловать на очередной этап нашего курса Redis и Spring Boot: Полное руководство по интеграции. В предыдущих статьях мы научились подключать Redis, использовать его как базу данных через репозитории и ускорять приложения с помощью кэширования.

Однако Redis — это не просто «быстрая Map<Key, Value>». Это многофункциональный швейцарский нож для backend-разработчика. Сегодня мы разберем три продвинутые темы, которые превратят вас из новичка в уверенного пользователя Redis:

Pub/Sub (Publish/Subscribe): Как построить систему обмена сообщениями в реальном времени.

Управление TTL (Time To Live): Тонкая настройка времени жизни данных и стратегии экспирации.

Глубокая настройка сериализации: Как эффективно хранить данные, экономя память и сохраняя читаемость.

Паттерн Pub/Sub: Обмен сообщениями

Традиционная модель взаимодействия сервисов — это синхронные запросы (REST, gRPC). Сервис А вызывает Сервис Б и ждет ответа. Но что делать, если нам нужно оповестить множество сервисов о событии, не зная заранее, кто именно слушает? Здесь на помощь приходит паттерн Издатель-Подписчик (Publish/Subscribe).

Как это работает в Redis?

В Redis механизм Pub/Sub работает по принципу «выстрелил и забыл» (fire-and-forget).

* Publisher (Издатель) отправляет сообщение в определенный канал (Channel). * Subscriber (Подписчик) слушает этот канал. * Redis мгновенно пересылает сообщение всем активным подписчикам этого канала.

!Схема распространения сообщений от одного издателя ко многим подписчикам через канал Redis

Важно понимать отличие от брокеров сообщений вроде RabbitMQ или Kafka: Redis не хранит сообщения. Если в момент отправки сообщения у канала не было подписчиков, сообщение исчезнет навсегда. Это делает Redis идеальным для:

* Чатов в реальном времени. * Обновления настроек микросервисов на лету. * Инвалидации локальных кэшей в распределенных системах.

Математика рассылки

Эффективность Pub/Sub в Redis можно оценить через временную сложность отправки сообщения.

Где: * — время, затрачиваемое на отправку сообщения. * — количество активных подписчиков на канал. * — размер самого сообщения в байтах.

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

Реализация в Spring Boot

Для работы с Pub/Sub нам понадобятся два компонента: контейнер слушателей и сам слушатель.

#### Шаг 1: Создание слушателя

Создадим сервис, который будет реагировать на сообщения.

#### Шаг 2: Конфигурация контейнера

В классе RedisConfig нам нужно зарегистрировать наш слушатель и привязать его к каналу.

#### Шаг 3: Отправка сообщений

Теперь любой компонент системы может отправить сообщение:

Управление временем жизни (TTL) вручную

В предыдущих статьях мы использовали аннотации @TimeToLive (в репозиториях) и настройки RedisCacheManager (в кэше). Но часто возникает необходимость установить TTL (Time To Live) программно для конкретного ключа, используя RedisTemplate.

Зачем это нужно?

Временные токены доступа: Например, SMS-код для входа, который живет 5 минут.

Ограничение частоты запросов (Rate Limiting): Блокировка пользователя на 1 час после 5 неудачных попыток входа.

Сессионные корзины: Хранение товаров в корзине неавторизованного пользователя в течение суток.

Работа с TTL через RedisTemplate

Установить срок жизни можно двумя способами: при создании записи и для уже существующей записи.

Стратегия пассивного и активного удаления

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

Пассивное удаление: Ключ удаляется в момент, когда клиент пытается его прочитать, и Redis видит, что время истекло.

Активное удаление: Redis периодически (по умолчанию 10 раз в секунду) выбирает случайные ключи с TTL и удаляет истекшие.

Вероятность того, что просроченный ключ останется в памяти, описывается вероятностной моделью, но Redis гарантирует, что доля просроченных ключей в памяти никогда не превысит 25% от общего числа ключей с TTL.

Глубокая настройка сериализации

Сериализация — это процесс превращения объекта Java в последовательность байтов для хранения в Redis.

По умолчанию RedisTemplate использует JdkSerializationRedisSerializer. Это надежно, но неэффективно.

Проблемы стандартной сериализации

Размер: Java-сериализация добавляет много метаданных (заголовки классов, версии).

Нечитаемость: Данные в Redis выглядят как бинарный мусор.

Совместимость: Прочитать эти данные можно только из Java-приложения.

JSON сериализация: Jackson

Мы уже касались GenericJackson2JsonRedisSerializer в прошлых статьях. Давайте разберем, как настроить его более тонко, чтобы решить проблему типизации.

Когда мы сохраняем List<User>, при десериализации Jackson может по умолчанию вернуть List<LinkedHashMap>, так как в JSON нет информации о классе User. Чтобы этого избежать, нужно настроить ObjectMapper.

Сравнение эффективности

Давайте сравним размер данных при разных подходах. Допустим, мы сохраняем объект User(id=1, name="Alice").

Использование GenericJackson2JsonRedisSerializer — это компромисс. Мы платим небольшим увеличением размера (из-за поля @class) за возможность автоматически восстанавливать сложные объекты Java без ручного приведения типов.

Заключение

В этой статье мы значительно расширили арсенал инструментов работы с Redis:

Разобрали паттерн Pub/Sub для создания реактивных приложений и узнали, что Redis не хранит сообщения, а лишь транслирует их.

Научились управлять временем жизни данных (TTL) программно, что критически важно для временных данных вроде сессий и кодов подтверждения.

Углубились в настройки сериализации, поняв разницу между чистым JSON и JSON с метаданными типов.

Эти знания позволяют использовать Redis не просто как кэш, а как полноценный компонент распределенной архитектуры. В следующей, заключительной статье курса, мы рассмотрим вопросы мониторинга, кластеризации и отказоустойчивости Redis в продакшн-среде.