Redis
Тема дорожной карты · Backend разработчик
Redis — open-source хранилище структур данных в памяти, используемое как база данных, кеш, брокер сообщений и хранилище сессий; это один из наиболее распространённых компонентов в современных бэкенд-архитектурах. Бэкенд-разработчики полагаются на Redis для субмиллисекундного кеширования результатов запросов PostgreSQL или MySQL через команды SET/GET/EXPIRE, хранения JWT-сессий, ограничения частоты запросов через атомарные операции INCR и EXPIRE, и pub/sub-обмена сообщениями между микросервисами. Структуры данных Redis — строки, хэши, упорядоченные множества, списки, потоки и битмапы — напрямую соответствуют распространённым бэкенд-паттернам: упорядоченные множества обеспечивают лидерборды, потоки лежат в основе облегчённых очередей событий как альтернатива Apache Kafka для нагрузок с меньшей пропускной способностью, а списки реализуют FIFO-очереди задач, потребляемые Celery-воркерами. Режимы персистентности Redis (снимки RDB и журнал дозаписи AOF) и репликация через Redis Sentinel или Redis Cluster обеспечивают долговечность и высокую доступность для продакшен-нагрузок в Kubernetes или Docker Compose. Реализации ограничения частоты запросов часто сочетают Redis с NGINX или middleware API-шлюза для применения порогов запросов на пользователя или IP через горизонтально масштабируемые экземпляры сервисов.
Как это работает
Redis покрывает document (MongoDB, CouchDB), key-value (Redis, DynamoDB, etcd), wide-column (Cassandra, HBase, ScyllaDB), graph (Neo4j, ArangoDB), search (Elasticsearch, OpenSearch). Каждая торгует ACID-гарантиями за конкретное свойство производительности или масштаба. Redis — универсальный швейцарский нож в памяти (кеш, очередь, pub/sub, distributed lock). Elasticsearch доминирует в full-text. MongoDB подходит для гибких JSON-данных, но требует дисциплины денормализации.
Когда применять
Redis — для кеша + rate limit + простых очередей: окупается в большинстве стеков. Elasticsearch / OpenSearch — когда нужен full-text за пределами LIKE %x%. MongoDB или DynamoDB — только если access-паттерн реально не ложится в реляционную модель (высокая частота записи на айтем, очень разнородные документы). Избегайте NoSQL "ради масштаба" до измерения боттлнека в Postgres — преждевременная оптимизация тут реальна.
Типичные ошибки
Ловушки Redis: MongoDB для реляционных данных ("гибкая схема" прячет связи — joins становятся application-side N+1); Redis как единственное durable-хранилище (это в основном память; persistence с оговорками); Elasticsearch как primary-БД (медленные апдейты, нет транзакций — индексируйте из Postgres); выбор NoSQL по хайпу, а не по read/write-паттернам. Определяйте запросы до хранилища.