Как кэшировали данные пользователей с использованием Redis и какой клиент применяли?
Что проверяют
Был ли у вас реальный опыт с кешем или вы знаете Redis по статьям. Интервьюер ждёт не код подключения, а решения: что кешировали, как инвалидировали, что было при падении Redis. Следом почти всегда спрашивают, почему выбрали именно этот клиент.
Как отвечать
Стройте ответ на своём проекте, примеры и цифры берите свои. Каркас такой:
- что и зачем: например, профиль и настройки пользователя, которые читаются на каждом запросе и меняются редко. Назовите доступную вам метрику: долю попаданий в кеш, нагрузку на базу до и после;
- клиент: в Spring Boot по умолчанию Lettuce, он потокобезопасный, работает на Netty, умеет асинхронный и реактивный режимы. У Jedis объект соединения нельзя делить между потоками, нужен пул или
JedisPooled. Redisson берут ради распределённых блокировок и готовых структур; - интеграция:
@EnableCaching,@Cacheable("users")на чтении,@CacheEvictили@CachePutна изменении,RedisCacheManagerс TTL черезRedisCacheConfiguration.entryTtl(). Сериализатор замените на JSON: JDK-сериализация по умолчанию ломается при изменении класса и нечитаема вredis-cli; - паттерн: cache-aside, ключи вида
user:42, TTL с небольшим случайным разбросом, чтобы ключи не истекали разом; - сбои: при недоступном Redis приложение идёт в базу, а не падает. От набега на один ключ есть
@Cacheable(sync = true), но он блокирует только внутри одного инстанса.
Если с Redis вы не работали, так и скажите и расскажите про кеш, который был: Caffeine или второй уровень кеша Hibernate. Затем объясните, что изменится при переходе на распределённый кеш.
Где спотыкаются
Рассказывают только про set и get, без инвалидации. Уточнение «пользователь сменил email, что отдаст кеш» остаётся без ответа.
Кешируют JPA-сущности целиком, с ленивыми связями и прокси Hibernate. Сериализация падает или тянет за собой пол-графа объектов.
Не задают TTL и maxmemory-policy. По умолчанию стоит noeviction, и когда память кончается, Redis начинает отказывать в записи.