Redis: in-memory база данных и архитектура

Redis кажется безобидным ускорителем ровно до того момента, пока в него не начинают складывать состояние, от которого зависит корректность бизнеса. Эта глава как раз помогает провести эту границу.

В реальных системах она полезна тем, что заставляет разделять быстрый слой доступа и надежный источник истины, а также думать о ключах, структурах данных, TTL и persistence не как о деталях реализации, а как о части архитектуры.

В интервью и инженерных обсуждениях этот материал особенно силен там, где нужно показать, что Redis решает конкретную проблему задержек и нагрузки, но не обязан автоматически становиться сердцем системы.

Практическая польза главы

Hot-path ускорение

Выделяйте latency-критичные участки в Redis, сохраняя database-of-record отдельно для надежной персистентности.

Структуры данных

Подбирайте key design и data structures (string/hash/zset/stream) под доступ и TTL-политику.

Надежность и limits

Явно учитывайте RDB/AOF компромиссы, eviction-политику, memory pressure и failover-поведение кластера.

Interview trade-offs

Показывайте, где Redis решает проблему, а где опасно превращать его в единственный источник истины.

Источник

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 систем.

История и контекст

2009

Первый публичный релиз

Redis появляется как open-source in-memory key-value store с фокусом на очень низкую latency.

2010-е

Расширение моделей данных и сценариев

Помимо простого кэша, Redis активно применяется для rate limiting, очередей, leaderboard и session store.

2013-2016

HA и масштабирование

Практики репликации, Sentinel и Redis Cluster формируют базовый production-подход к отказоустойчивости и шардированию.

2020+

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.

Ключевые команды

GET/SETINCR/DECRMGET/MSETEXPIRE

Типичные сценарии

Cache-aside
Session token
Atomic counters

Пример

SET user:1001:profile '{"name":"Alice"}' EX 300
INCR page:home:views

High-Level Architecture

Ниже high-level контур Redis в продуктовой системе: клиентский слой, execution path команд, in-memory data model, durability и cluster/failover механики.

Clients and protocol

RESP2/RESP3redis-cliClient librariesTLS + ACL

Layer transition

Command processing

Event loopAtomic commandsPipeliningLua / Functions

Layer transition

In-memory data model

String/HashList/Set/ZSETStreamsProbabilistic structs

Layer transition

Persistence

RDB snapshotsAOFappendfsync policyAOF rewrite

Layer transition

Replication and failover

Primary/ReplicaPSYNCSentinelFailover

Layer transition

Cluster operations

Hash slotsReshardingEviction policyMonitoring

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

Sub-ms reads/writesIn-memory accessPipeline batching

System design use cases

Cache/session storeRate limitingLeaderboard/real-time counters

Operational trade-offs

RAM costEviction tuningReplication lag on read replicas

Read / Write Path через компоненты

Диаграмма объединяет write и read path с пояснениями: как Redis-команды маршрутизируются, исполняются и подтверждаются в single-node и cluster-сценариях.

Read/Write Path Explorer

Интерактивный разбор прохождения Redis-команд через компоненты инстанса/кластера.

Client Command

SET HSET XADD

Routing

slot owner

Command Execute

event loop

Durability + Replica

AOF/RDB + PSYNC

Ack + Visibility

primary state

Client Command

SET HSET XADD

Routing

slot owner

Command Execute

event loop

Durability + Replica

AOF/RDB + PSYNC

Ack + Visibility

primary state

Write path: команда маршрутизируется на owner-узел, изменяет in-memory state, затем подтверждается с учетом репликации/persistence.

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 MKSTREAM

ACL-профиль для application user

ACL SETUSER

Ограничиваем доступ приложению по namespace и группам команд.

ACL SETUSER app on >S3cr3t
~app:*
+@read +@write
-FLUSHALL

Связанные главы

Database Selection Framework - Фреймворк выбора СУБД, чтобы понять, когда Redis нужен как отдельный low-latency слой, а когда требуется другой тип базы.
Стратегии кэширования: Cache-Aside, Read-Through, Write-Through, Write-Back - Паттерны кэширования и trade-offs по consistency/latency, где Redis чаще всего используется как cache backend.
Репликация и шардинг - Практика HA и scale: replica lag, failover-сценарии, shard key и операционные риски кластеризации.
Key-Value Database - Case study про проектирование распределённой KV-системы и сравнение её принципов с использованием Redis в проде.
Введение в хранение данных - Как комбинировать in-memory слой с persistent storage и согласовать это с API/consistency требованиями.
CAP теорема - Фундаментальный контекст компромиссов доступности и консистентности для распределённых data-слоёв.