Базы данных
Redis: in-memory хранилище в продакшне
Instagram в 2012 году обрабатывал 1 миллиард запросов в день с командой из 13 человек. Секрет - Redis. Лайки, подписчики, activity feed - всё кешировалось в Redis. Когда пользователь ставил лайк, это была одна Redis-операция <1ms, а не запрос к PostgreSQL.
- **Twitter**: Redis Sorted Set для trending topics - реальное время без агрегации в БД
- **GitHub**: Redis + Sidekiq для 50+ миллионов фоновых задач в день (CI/CD, уведомления, webhooks)
- **Stack Overflow**: Redis для кеша всего сайта - 95%+ запросов обслуживается без обращения к SQL
Структуры данных Redis
Redis - не просто key-value store. Это сервер структур данных. Каждый тип имеет специализированные команды с оптимальной сложностью. String - любое значение до 512MB. List - двусвязный список. Hash - плоский объект. Set - уникальные элементы. Sorted Set (ZSet) - элементы с float score, всегда упорядочены.
Discord хранит список online пользователей сервера в Redis Set. При подключении - SADD, при отключении - SREM, онлайн-каунт - SCARD. Операции O(1). Discord обслуживает 19 миллионов одновременных пользователей - всё работает через Redis.
Какая структура данных Redis оптимальна для leaderboard с реальным временем (нужен быстрый ранг игрока)?
Persistence: RDB и AOF
Redis - in-memory БД, но поддерживает два режима persistence. RDB (Redis Database Backup) - периодические снапшоты всех данных. AOF (Append-Only File) - лог каждой write-операции. Можно использовать оба вместе.
| Параметр | RDB | AOF |
|---|---|---|
| Скорость записи | Быстрее (батч) | Медленнее (каждая команда) |
| Потеря данных при crash | Данные с момента последнего снапшота | Максимум 1 секунда (fsync каждую секунду) |
| Время восстановления | Быстрее | Медленнее (replay лога) |
| Размер файла | Компактный | Растёт, нужна rewrite |
Приложение использует Redis для кеша сессий. Данные восстановимы из PostgreSQL. Какой режим persistence выбрать?
Pub/Sub и Redis Streams
Redis Pub/Sub - fire-and-forget messaging. Publisher отправляет в channel, все subscribers получают. Проблема: если subscriber офлайн - сообщение потеряно. Нет истории, нет acknowledgment. Подходит для live уведомлений, chat broadcast.
Redis Streams (добавлены в Redis 5.0) решают эти проблемы. Это append-only лог с consumer groups, acknowledgment, и историей сообщений. Аналог упрощённого Kafka внутри Redis.
Чем Redis Streams отличается от Pub/Sub в контексте надёжности?
Lua скрипты и атомарность
Redis однопоточный - все команды выполняются последовательно. Но между двумя командами другой клиент может вставить свою. Для атомарных операций из нескольких шагов используются Lua скрипты: весь скрипт выполняется как одна атомарная операция.
Зачем использовать Lua скрипт для rate limiter вместо двух отдельных команд GET + INCR?
Redis Cluster
Redis Cluster автоматически шардирует данные по 16384 слотам. Ключ хешируется в слот, слот назначен на master ноду. Каждый master имеет N replica для failover. Cluster обеспечивает horizontal scaling и высокую доступность без стороннего proxy.
Ограничение Cluster: multi-key операции (MSET, MGET, SUNION) работают только если все ключи в одном слоте. Hash tags {bracket} позволяют принудительно поместить ключи в один слот. Lua скрипты в Cluster также требуют, чтобы все KEYS были в одном слоте.
Redis теряет все данные при перезапуске
Redis поддерживает RDB снапшоты и AOF лог. С AOF everysec теряется максимум 1 секунда данных. Redis Cluster автоматически реплицирует данные на replica ноды.
Это миф из ранних версий Redis когда persistence не была дефолтной. Современный Redis с правильным конфигом - надёжное персистентное хранилище.
Почему MGET user:1 user:2 user:3 может вернуть ошибку в Redis Cluster?
Ключевые идеи
- **Структуры данных**: String, List, Hash, Set, ZSet - у каждой своя область применения и O(log N) или O(1) операции
- **RDB vs AOF**: RDB быстрее, AOF надёжнее; pure cache = no persistence, критичные данные = AOF everysec
- **Lua для атомарности**: несколько операций в одном атомарном блоке - защита от race conditions без MULTI/EXEC
Связанные темы
Redis применяется в нескольких паттернах системного дизайна:
- Кеширование — Redis - стандарт для cache-aside и write-through паттернов
- Connection Pooling — Redis сам управляет пулом соединений через multiplexing
- Time-series — Redis TimeSeries модуль для хранения метрик в реальном времени
Вопросы для размышления
- Когда Redis Streams предпочтительнее Kafka для event-driven архитектуры?
- Приложение использует Redis для сессий и Pub/Sub для уведомлений. Что произойдёт с пользователями при перезапуске Redis без persistence?
- Как hash tags влияют на равномерность распределения данных в Redis Cluster?