Источник
Wikipedia: Redis
История Redis, архитектурные особенности и место in-memory хранилища в современных системах.
Официальный сайт
Redis
Официальная документация по data structures, persistence, replication, Sentinel и Cluster.
Redis - in-memory key-value хранилище с богатым набором структур данных и минимальной latency. В системном дизайне Redis часто выступает отдельным operational layer: кэш, сессии, счётчики, очереди/streams и быстрые stateful primitive для high-throughput систем.
История и контекст
Первый публичный релиз
Redis появляется как open-source in-memory key-value store с фокусом на очень низкую latency.
Расширение моделей данных и сценариев
Помимо простого кэша, Redis активно применяется для rate limiting, очередей, leaderboard и session store.
HA и масштабирование
Практики репликации, Sentinel и Redis Cluster формируют базовый production-подход к отказоустойчивости и шардированию.
Cloud-first эксплуатация
Managed Redis становится стандартом для многих команд: акцент смещается на SLA, наблюдаемость и стоимость памяти.
Ключевые архитектурные элементы
Event loop и атомарные команды
Команды выполняются в последовательном event loop, что упрощает модель concurrency и дает предсказуемое время отклика.
In-memory структуры данных
Strings, Hashes, Lists, Sets, Sorted Sets, Streams позволяют решать широкий спектр задач без отдельного query planner.
Durability: RDB и AOF
Redis поддерживает различные режимы сохранности: snapshot-подход, append-only log и их комбинации.
Replication и Cluster
Для масштабирования и HA используются primary/replica топологии, Sentinel и hash-slot шардирование в Redis Cluster.
Структуры данных Redis: почему это больше, чем key/value
Redis хранит типизированные структуры и даёт специализированные команды для каждой из них. За счёт этого он покрывает не только кэш, но и прикладные stateful-сценарии с атомарными операциями.
Структуры данных Redis: больше, чем key/value
В Redis ключ ссылается не просто на строку, а на типизированную in-memory структуру со специализированными атомарными командами.
Почему Redis — это не "просто key/value"
- Value в Redis имеет тип (String/Hash/List/Set/ZSET/Stream), а не является непрозрачным blob.
- Операции выполняются на стороне сервера атомарно, что снижает round-trips и упрощает конкурентный доступ.
- Каждый тип даёт прикладные примитивы: leaderboard, очереди, счётчики, ленты событий, approximate analytics.
- Data structures + TTL + persistence + replication формируют полноценный operational data layer.
String
Универсальный тип для кэша, счётчиков, флагов и небольших JSON payload.
Ключевые команды
Типичные сценарии
- Cache-aside
- Session token
- Atomic counters
Пример
SET user:1001:profile '{"name":"Alice"}' EX 300
INCR page:home:viewsHigh-Level Architecture
Ниже high-level контур Redis в продуктовой системе: клиентский слой, execution path команд, in-memory data model, durability и cluster/failover механики.
System view
Redis is typically used as an in-memory operational layer for low-latency reads/writes, often placed in front of durable transactional databases.
Latency profile
System design use cases
Operational trade-offs
Read / Write Path через компоненты
Диаграмма объединяет write и read path с пояснениями: как Redis-команды маршрутизируются, исполняются и подтверждаются в single-node и cluster-сценариях.
Read/Write Path Explorer
Интерактивный разбор прохождения Redis-команд через компоненты инстанса/кластера.
Write path
- Приложение отправляет write-команду (`SET`, `HSET`, `XADD`) на Redis endpoint.
- В кластере команда идёт на primary-владелец hash slot; кросс-слотовые операции требуют отдельного дизайна ключей.
- Primary применяет изменение в RAM и асинхронно реплицирует его на replicas (PSYNC).
- Durability настраивается через RDB/AOF; баланс latency и надежности зависит от `appendfsync`/политики persistence.
Когда выбирать Redis
Хорошо подходит
- Кэширование горячих данных и API-ответов с sub-ms требованиями.
- Session store, rate limiter, distributed counters и leaderboard.
- Pub/Sub и Streams для real-time событий и лёгких очередей.
- Сценарии, где простая модель данных и скорость важнее сложных ad-hoc запросов.
Стоит избегать
- Как единственный source of truth для критичных бизнес-данных без продуманной persistence-стратегии.
- Сложная аналитика и произвольные join-подобные запросы на больших наборах данных.
- Нагрузки, где объем рабочих данных значительно превышает доступную RAM.
- Системы без готовности к управлению eviction, replication lag и backup/recovery практиками.
Практика: DDL и DML
Ниже практические команды Redis: DDL-like операции для keyspace/config и DML команды для чтения/записи данных.
Примеры DDL и DML в Redis
В Redis нет классического SQL DDL, но есть DDL-like операции для keyspace, durability и access policy.
DDL-like слой в Redis обычно про operational schema: durability-политики, ACL и подготовку структур (например, consumer groups).
Настройка durability и memory policy
CONFIG SETОпределяем поведение AOF и eviction при ограничении RAM.
CONFIG SET appendonly yes
CONFIG SET appendfsync everysec
CONFIG SET maxmemory 4gb
CONFIG SET maxmemory-policy allkeys-lruПодготовка stream-контура: consumer group
XGROUP CREATEСоздаем stream + consumer group как структурную основу для обработки событий.
XGROUP CREATE orders:events order-service 0 MKSTREAMACL-профиль для application user
ACL SETUSERОграничиваем доступ приложению по namespace и группам команд.
ACL SETUSER app on >S3cr3t
~app:*
+@read +@write
-FLUSHALL