Redis

Redis нужен, как только приложению требуется доступ к данным быстрее миллисекунды — и этот порог наступает раньше, чем большинство команд ожидает. Типичные триггеры: время ответа на запросы к базе данных превышает 100 мс под продакшен-нагрузкой, управление сессиями становится узким местом при горизонтальном масштабировании, или появляется потребность в real-time функциях — лидерборды, мгновенные уведомления, rate limiting. Redis также подходит как лёгкий координационный слой между микросервисами: распределённые блокировки, pub/sub, очереди задач с жёсткими бюджетами по задержке. В наших проектах добавление Redis-кеширования перед PostgreSQL обычно снижает p95 времени ответа API на 60–80% и уменьшает нагрузку на CPU базы данных на 40–50%.

Redis хранит все данные в оперативной памяти и использует однопоточный event loop, исключая накладные расходы на переключение контекста и блокировки — каждая операция выполняется за микросекунды без конкуренции. Один экземпляр Redis на современном оборудовании обрабатывает 100 000–300 000 операций в секунду в зависимости от сложности команды и размера данных. Для простых GET/SET с небольшими значениями пропускная способность превышает 250 000 ops/sec; более сложные операции — запросы диапазонов sorted set — всё равно дают 80 000–150 000 ops/sec. Когда одного узла недостаточно, Redis Cluster распределяет данные между шардами с линейным масштабированием — кластер из 6 узлов обеспечивает примерно 6-кратную пропускную способность. Мы замеряем и бенчмаркаем каждое Redis-развёртывание под проектируемую пиковую нагрузку с 2-кратным запасом.

Memcached — чистый key-value кэш с простой строковой моделью значений, тогда как Redis предлагает богатые структуры данных — хэши, sorted sets, списки, стримы, HyperLogLog, битовые карты и геопространственные индексы — которые выходят далеко за рамки кэширования. Redis поддерживает персистентность (RDB-снэпшоты и AOF-логирование), репликацию, Lua-скрипты, pub/sub и транзакции, что делает его пригодным и как кэш, и как лёгкая прикладная БД. Преимущество Memcached — многопоточная архитектура, которая лучше утилизирует многоядерные CPU для чисто кэширующих нагрузок. На практике мы выбираем Memcached только когда нагрузка — исключительно простое key-value кэширование без потребности в структурах данных или персистентности. В 95% проектов Redis покрывает кэширование плюс дополнительные задачи (сессии, очереди, rate limiting), исключая необходимость в отдельной системе.

Redis предлагает два механизма персистентности, которые мы настраиваем в зависимости от критичности данных. RDB-снэпшоты создают резервную копию состояния через настраиваемые интервалы (например, каждые 60 секунд при изменении минимум 1 000 ключей) — компактные файлы с быстрым восстановлением, но с возможной потерей данных за последний интервал. AOF (Append Only File) логирует каждую операцию записи и может синхронизироваться раз в секунду или на каждую запись, сокращая возможную потерю максимум до одной секунды. Мы обычно включаем оба: AOF для надёжности, RDB для быстрого аварийного восстановления. Для высокой доступности Redis Sentinel мониторит primary-ноды и автоматически повышает реплику за секунды. В Redis Cluster у каждого шарда свои реплики, поэтому сбой одного узла не вызывает недоступности данных.

Стоимость Redis зависит от объёма данных: цены AWS ElastiCache варьируются от $13/мес за cache.t3.micro (0,5 ГБ) до $900+/мес за cache.r7g.4xlarge (105 ГБ), а кластерные конфигурации умножают стоимость на число узлов. Для self-managed на Kubernetes основная статья — RAM, выделенная Redis-подам. Мы оптимизируем память несколькими способами: выбор самой компактной структуры данных (хэши с ziplist-кодировкой используют в 10 раз меньше памяти, чем отдельные строковые ключи), установка адекватных TTL, включение сжатия для крупных значений и настройка maxmemory-policy. В одном e-commerce проекте мы сократили потребление Redis с 12 ГБ до 3,5 ГБ, переключившись с плоских строковых ключей на хэш-объекты и настроив hash-max-ziplist-пороги, сэкономив ~$400/мес на хостинге.