Сценарии использования Redis для кэширования и очередей на Dockup

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

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

Как создать управляемый Redis?

Создайте Redis в выбранном workspace:

dockup db create \
  --name app-redis \
  --type redis \
  --json

Проверьте параметры базы данных:

dockup db list --json

Сохраните полученные данные для подключения вне системы контроля версий и передайте их подключаемому сервису в виде секрета:

dockup env set REDIS_URL="$REDIS_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

Повторное развёртывание создаёт новый контейнер приложения с обновлённым окружением. Перезапуск старого контейнера не применяет новое сохранённое целевое значение.

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

Когда следует использовать Redis в качестве кэша?

Кэш снижает объём повторной работы или задержку, сохраняя производные данные. Источник истины остаётся в другом месте — обычно в PostgreSQL, MySQL, MongoDB, стороннем API или детерминированном вычислении.

Продуманная архитектура кэша определяет:

• Формат и пространство имён ключей кэша.
• Время жизни.
• Максимально допустимую устарелость данных.
• Триггер инвалидации.
• Поведение при промахе кэша.
• Поведение при недоступности Redis.
• Защиту от эффекта «стада».
• Данные, которые ни в коем случае нельзя кэшировать.

Сбой	Безопасное поведение кэша
Ключ отсутствует	Повторно вычислить данные или прочитать источник истины
Redis недоступен	Переключиться на источник с ограничением нагрузки
Устаревшая запись	Удалить по истечении срока или инвалидировать
Изменение сериализации	Версионировать пространство имён ключей
Нехватка памяти	Сначала вытеснять данные, которые можно восстановить
Горячий ключ	Добавить локальный кэш, шардинг или объединение запросов

Не делайте всё приложение недоступным только из-за отказа необязательного кэша. Используйте ограниченные тайм-ауты и fallback-сценарии. В то же время не скрывайте все сбои: длительная недоступность кэша может перегрузить исходную базу данных.

Что меняется, когда Redis используется как очередь задач?

Очередь содержит ожидающие задачи, поэтому приложение должно определить семантику доставки и восстановления. Сам Redis — это сервер структур данных; гарантии зависят от библиотеки очереди и протокола работы воркеров.

Определите:

1. Когда задача считается принятой?
2. Когда она подтверждается?
3. Что произойдёт, если воркер завершится после выполнения побочного эффекта, но до подтверждения?
4. Как задерживаются и ограничиваются повторы?
5. Куда попадают задачи, завершившиеся окончательной ошибкой?
6. Как сделать повторное выполнение безопасным?
7. Как отслеживается глубина очереди?
8. Можно ли восстановить payload задачи?

Создавайте идемпотентных воркеров. После сбоя платёж, отправка письма или импорт данных могут быть доставлены более одного раза. Используйте бизнес-ключ идемпотентности и записывайте факт выполнения в базе данных — источнике истины.

Разделяйте имена очередей по типу нагрузки и приоритету. Медленная задача обработки медиа не должна блокировать обработку сброса пароля или webhook. Не помещайте секреты в payload задач, если достаточно передать идентификатор ссылки.

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

Как приватная сеть подключает сервисы к Redis?

Включите сеть проекта:

dockup network enable production --json

Сервис Redis становится доступен по стабильному имени хоста <slug>.internal из сервисов того же проекта. Повторно разверните приложение, чтобы Dockup мог передать ему внутренние переменные подключения.

Чтобы сделать Redis доступным только в приватной сети:

dockup db private production/app-redis --json

Восстановите публичный listener, если это необходимо:

dockup db private production/app-redis --off --json

Приватная сеть убирает путь через публичный интернет для трафика внутри одного проекта, но не заменяет аутентификацию. Храните данные для подключения к Redis как секрет и ограничьте список сервисов, которые их получают.

Разные проекты не могут обращаться к приватной сети друг друга. Это ограничение удобно, когда production и staging не должны совместно использовать ключи кэша или задачи очереди.

Полную модель см. в статье приватная сеть и внутренние домены.

Как сбои Redis должны влиять на приложение?

Перед написанием кода восстановления классифицируйте сценарий использования.

Сценарий	Допустимость потери	Реакция на сбой
Кэш HTML-фрагментов	Высокая	Восстановить данные из источника
Хранилище сессий	Низкая или средняя	Пользователи могут выйти из системы; предусмотрите fallback
Счётчики ограничения частоты запросов	Зависит от политики	Явно выбрать режим fail open или fail closed
Очередь задач	Низкая	Прекратить приём или сохранять задачи в другом месте
Распределённая блокировка	Очень низкая для критических секций	Использовать fencing/idempotency
Кэш функциональности	Высокая	Использовать значение по умолчанию или источник

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

Проверьте размер Redis и runtime-логи использующего его приложения:

dockup db size production/app-redis --json
dockup logs production/api --json

Рост размера может указывать на отсутствие срока действия, неконтролируемый рост очереди, слишком большие payload или заброшенные пространства имён. Не рассматривайте перезапуск базы данных как первую реакцию на тайм-ауты приложения: сначала проверьте конфигурацию, сеть и поведение клиента.

Как связаны Redis, резервное копирование, миграция и мониторинг?

Dockup предоставляет workflow резервного копирования управляемой базы данных:

dockup db backups production/app-redis --json
dockup db backup production/app-redis --json

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

Переместите Redis между узлами:

dockup db migrate production/app-redis \
  --node <nodeId> \
  --json

Заранее оцените влияние миграции на клиентов и воркеров. До запуска в production убедитесь, что повторное подключение, повторы и идемпотентность работают корректно.

Помимо размера базы данных, отслеживайте метрики на уровне приложения:

• Доля попаданий в кэш.
• Задержка промахов.
• Вытеснения.
• Глубина очереди и возраст самой старой задачи.
• Количество успешно выполненных, повторённых и завершившихся ошибкой задач.
• Конкурентность воркеров.
• Ошибки подключения к Redis.
• Размер payload.

Dockup измеряет потребление CPU, RAM и диска каждую минуту относительно баланса тарифа. Рекомендуемый тариф Pro стоит $20 в месяц и включает кредит на использование в размере $20, но решения о ёмкости следует принимать на основе метрик нагрузки, а не названия тарифа.

Как выглядит безопасный production-чеклист для Redis?

Перед запуском проверьте:

1. Точный target project/db.
2. Зоны ответственности кэша и очереди документированы.
3. URL подключения хранится как замаскированный секрет.
4. Политика приватной сети определена.
5. Для каждого кэша задан TTL или явная инвалидация.
6. Воркеры очереди идемпотентны.
7. Повторы и dead-letter-поведение определены системой очередей.
8. Настроены алерты по размеру и глубине очереди.
9. Понятны ценность и ограничения резервного копирования.
10. Перезапуск и миграция требуют подтверждения.

Пример разделения кэша и очереди

Небольшое приложение может начать с одной базы данных Redis, если риски невелики, но использовать понятные префиксы ключей:

cache:user-profile:v2:<user-id>
cache:catalog:v5:<product-id>
queue:email:waiting
queue:email:active
lock:invoice:<invoice-id>

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

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

Операции с реляционным источником истины см. в статье управляемый PostgreSQL. Более общие варианты наращивания ёмкости описаны в статье стратегии масштабирования баз данных. Актуальные команды для работы с базами данных приведены в справочнике Dockup CLI.

Определяйте эволюцию ключей и payload

Данные кэша и очереди живут дольше одного процесса приложения. Во время blue-green cutover новый релиз может читать ключи, записанные предыдущим релизом. Версионируйте пространства имён ключей и payload задач, чтобы обе версии могли работать одновременно.

Для очередей добавляйте версию payload и сохраняйте в воркерах поддержку как минимум тех версий, которые ещё могут находиться в ожидании. При откате развёртывания старый код может быть восстановлен, пока задачи нового формата остаются в Redis. Без обратной совместимости откат приложения может увеличить число ошибок.

Целенаправленно тестируйте нехватку ресурсов

В среде, не предназначенной для production, протестируйте отсутствующие ключи, медленные ответы Redis, сбросы соединений, накопление очереди, повторную доставку и заполненную или почти заполненную память. Проверьте, переходит ли приложение в режим fail open или fail closed, повторяет ли запросы и не перегружает ли другую зависимость.

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

Сохраняйте путь восстановления через источник истины

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

Начните с проверяемого развёртывания

Создайте Redis в проекте, не предназначенном для production, протестируйте fallback кэша и повторную доставку задач, а затем явно определите политику сбоев до передачи критически важной работы.

Начать бесплатно на app.dockup.ai. Тариф Free стоит $0 в месяц, включает стартовый кредит $10 и поддерживает один workspace, три базы данных и три развёртывания.

FAQ

Может ли Dockup создать управляемый Redis?

Да. Используйте команду создания управляемой базы данных с типом redis, затем подключите приложение с помощью полученных данных для подключения, сохранённых как секрет.

Следует ли хранить данные кэша и очереди в одном экземпляре Redis?

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

Гарантирует ли Redis, что задача из очереди будет выполнена ровно один раз?

Нельзя исходить из общей гарантии выполнения ровно один раз. Семантика доставки зависит от библиотеки очереди и архитектуры воркеров, поэтому побочные эффекты должны быть идемпотентными.

Можно ли использовать приватную сеть Dockup с Redis?

Да. Включите сеть проекта, повторно разверните использующие Redis сервисы для получения внутренних переменных и при необходимости сделайте базу данных Redis доступной только в приватной сети.

Достаточно ли резервной копии Redis для критически важной очереди задач?

Не обязательно. Резервная копия отражает состояние на определённый момент времени и может не включать более новые принятые задачи. Храните восстанавливаемые исходные записи и определите восстановление задач на уровне приложения.