Redis в бэкенде
Вопрос
Где в типичном бэкенде используют Redis и какие у этого риски?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Кеш перед базой с TTL, сессии, счётчики и rate limiting, блокировки, лидерборды на sorted set
Почему быстрый: данные в памяти, простые структуры, команды атомарны
Риск потери данных: RDB и AOF, поэтому не единственное хранилище для важного
Память конечна: maxmemory и политика вытеснения (allkeys-lru и т.п.)
Кеш: инвалидация, лавина промахов, горячие ключи
Распределённая блокировка на Redis не даёт строгих гарантий при сбоях
Что могут спросить следом
- Что произойдёт, когда Redis упрётся в maxmemory?
- Как защититься от лавины запросов в базу при истечении популярного ключа?
Разбор
Redis держит данные в памяти и выполняет команды по очереди, поэтому быстрый и атомарный на уровне команды. Типично его ставят как кеш перед базой с TTL, хранят сессии, счётчики и ограничение частоты запросов через INCR с EXPIRE, делают простые блокировки через SET NX EX, лидерборды на sorted set, лёгкие очереди на списках или стримах. Риски: во-первых, сохранность. Снимки RDB и журнал AOF уменьшают потерю, но гарантий как у PostgreSQL нет, поэтому важные данные живут в базе. Во-вторых, память конечна: нужно задать maxmemory и политику вытеснения, иначе при заполнении запись начнёт падать с ошибкой. В-третьих, кешу свойственны свои проблемы: инвалидация, лавина запросов в базу при истечении популярного ключа, горячие ключи. И блокировки на Redis хороши для эффективности, а для строгой корректности при сбоях нужны fencing-токены или блокировки в самой базе.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.