Как работали с Redis: конфигурировали ли и использовали ли напрямую

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

Где у вас проходит граница между «подключил стартер и повесил @Cacheable» и пониманием, как Redis ведёт себя под нагрузкой и при нехватке памяти. Следом часто спрашивают, что будет, когда память закончится, и как вы инвалидировали кеш.

Как отвечать

Разделите ответ на две части, как в вопросе.

Использование из Java:

• клиент: в Spring Boot по умолчанию Lettuce с потокобезопасным соединением, Jedis подключается отдельно. Для распределённых блокировок часто берут Redisson;
• абстракции: RedisTemplate и StringRedisTemplate для прямых операций, @Cacheable с RedisCacheManager для кеша, Spring Session для сессий. Настройки в Spring Boot 3 живут под spring.data.redis.*;
• сериализация: RedisTemplate по умолчанию пишет через JDK-сериализацию, в ключах нечитаемые байты. Обычно ставят StringRedisSerializer для ключей и JSON-сериализатор для значений;
• структуры: не только строки, но и hash для объектов, sorted set для рейтингов, INCR с EXPIRE для rate limit.

Конфигурация сервера:

• память: maxmemory и maxmemory-policy. По умолчанию политика noeviction, при заполнении запись падает с ошибкой. Для кеша ставят allkeys-lru или allkeys-lfu;
• персистентность: RDB-снимки через save и AOF через appendonly yes с appendfsync everysec. Для чистого кеша её часто отключают;
• TTL: у каждой записи кеша должен быть срок, в Spring это entryTtl в RedisCacheConfiguration.

Если конфигурировали только клиент, так и скажите: сервер поднимали админы или это был managed-сервис в облаке.

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

Используют KEYS * в продакшене. Команды Redis выполняются в одном потоке, и полный обход ключей блокирует всех клиентов, для перебора есть SCAN.

Хранят в Redis единственную копию важных данных и удивляются потере после рестарта или вытеснения. Кеш должен уметь пропасть без последствий.

Считают, что keyspace notifications спасают от потери ключей по TTL. Это уведомления без гарантии доставки: если подписчик был отключён, событие потеряно.