Использовали ли вы Redis или аналогичные технологии?
Что проверяют
Есть ли у вас реальный опыт с распределённым кэшем или хранилищем в памяти и понимаете ли вы его ограничения. Следом почти всегда спрашивают, как вы инвалидировали кэш и что будет, если Redis упадёт.
Как отвечать
Ответ строится на ваших примерах, общие слова про «быстрое хранилище в памяти» ничего не дают. Удобный каркас: задача, почему выбрали Redis, как интегрировали, какая была проблема, какой результат в цифрах.
Типовые сценарии, из которых стоит выбрать свои:
- кэш:
@CacheableповерхRedisCacheManagerв Spring, стратегия cache-aside, TTL на каждый тип данных; - сессии: Spring Session с хранением в Redis, чтобы приложение масштабировалось горизонтально без липких сессий;
- распределённые блокировки и лимиты: Redisson, счётчики на
INCRиEXPIREдля rate limiting; - очереди и события: Streams или pub/sub, с оговоркой, что pub/sub не хранит сообщения для отключённых подписчиков.
По Java-стеку: Spring Data Redis в Spring Boot по умолчанию работает через клиент Lettuce, Jedis подключается отдельно. Упомяните настройку памяти: maxmemory и maxmemory-policy. Для кэша обычно ставят allkeys-lru, а по умолчанию стоит noeviction, и при заполнении запись просто падает с ошибкой.
«Аналогичные технологии» тоже стоит назвать: Memcached, Hazelcast, локальный Caffeine, Valkey (форк Redis под лицензией BSD). Если с Redis вы не работали, скажите честно и расскажите о близком опыте, например о локальном кэше на Caffeine, и о том, что изменилось бы при переходе на распределённый.
Где спотыкаются
Выдают TTL за решение консистентности. TTL лишь ограничивает, насколько устаревшими могут быть данные, а инвалидация при записи нужна отдельно.
Используют KEYS * на проде. Команда обходит всё пространство ключей и блокирует сервер, для перебора есть SCAN.
Оставляют сериализатор по умолчанию у RedisTemplate. Это JDK-сериализация: в Redis лежат нечитаемые байты, а изменение класса ломает чтение старых записей. Обычно берут JSON или строковый сериализатор.