Робочі навантаження Redis для cache і queue у Dockup

Робочі навантаження Redis cache і queue можуть використовувати один і той самий керований Redis-сервіс, але мають різні вимоги до коректності. Cache зазвичай можна відновити після втрати. Queue може містити завдання, які не можна непомітно втратити або виконати двічі.

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

Як створити керований Redis?

Створіть Redis у вибраному workspace:

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

Перевірте цільову базу даних:

dockup db list --json

Збережіть отримані дані для підключення поза системою контролю версій і передайте їх сервісу, який їх використовує, як secret:

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

dockup deploy production/api --wait --json

Повторне розгортання створює новий контейнер застосунку з оновленим environment. Перезапуск старого контейнера не застосовує щойно збережене бажане значення.

Використовуйте окремі Redis databases або instances, якщо поведінка eviction для cache і критичне зберігання queue не мають конкурувати за одну й ту саму пам’ять. Ізоляція також спрощує діагностику інцидентів і контроль доступу.

Коли Redis варто використовувати як cache?

Cache зменшує обсяг повторної роботи або затримку, зберігаючи похідні дані. Джерело істини залишається в іншому місці — зазвичай у PostgreSQL, MySQL, MongoDB, зовнішньому API або детермінованому обчисленні.

Надійний дизайн cache визначає:

• Формат cache key і namespace.
• Time to live.
• Максимально прийнятну застарілість даних.
• Тригер інвалідації.
• Поведінку під час cache miss.
• Поведінку, коли Redis недоступний.
• Захист від thundering herd.
• Дані, які в жодному разі не можна кешувати.

Збій	Безпечна поведінка cache
Ключ відсутній	Повторно обчислити або прочитати з джерела істини
Redis недоступний	Перейти до джерела з rate protection
Застарілий запис	Видалити після завершення терміну дії або інвалідувати
Зміна серіалізації	Версіонувати key namespace
Нестача пам’яті	Спочатку видаляти дані, які можна відновити
Hot key	Додати local cache, sharding або request coalescing

Не робіть увесь застосунок недоступним лише через те, що необов’язковий cache не працює. Використовуйте обмежені timeouts і fallback-шляхи. Водночас не приховуйте всі збої: тривала недоступність cache може перевантажити вихідну базу даних.

Що змінюється, коли Redis використовується як job queue?

Queue містить завдання, що очікують на виконання, тому застосунок має визначити семантику доставки й відновлення. Redis сам по собі є сервером структур даних; гарантії залежать від бібліотеки queue та протоколу worker.

Визначте:

1. Коли завдання вважається прийнятим?
2. Коли воно підтверджується?
3. Що відбувається, якщо worker завершує роботу після виконання side effect, але до підтвердження?
4. Як відкладаються та обмежуються retry?
5. Куди потрапляють завдання, які остаточно завершилися помилкою?
6. Як зробити повторне виконання безпечним?
7. Як відстежується queue depth?
8. Чи можна відновити payload завдання?

Створюйте idempotent workers. Платіж, email або імпорт даних можуть бути доставлені більше одного разу після збою. Використовуйте business idempotency key і записуйте завершення операції у базі даних — джерелі істини.

Розділяйте queue names за типом навантаження та пріоритетом. Повільне завдання обробки медіа не має блокувати обробку password reset або webhook. Не додавайте secrets до payload завдань, якщо достатньо reference ID.

Розгортання Redis cache і queue має документувати, які keys можна безпечно видаляти, а які представляють бізнесові завдання.

Як private networking підключає сервіси до Redis?

Увімкніть мережу проєкту:

dockup network enable production --json

Redis-сервіс стає доступним за стабільним hostname <slug>.internal із сервісів у тому самому проєкті. Повторно розгорніть застосунок, щоб Dockup міг передати йому internal connection variables.

Щоб зробити Redis доступним лише приватно:

dockup db private production/app-redis --json

Відновіть public listener, коли це потрібно:

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

Private networking прибирає шлях через публічний інтернет для трафіку між сервісами одного проєкту, але не замінює authentication. Зберігайте Redis connection material як secret і обмежте перелік сервісів, які його отримують.

Різні проєкти не можуть отримувати доступ до приватних мереж один одного. Ця межа може бути корисною, коли production і staging не мають спільно використовувати cache keys або queue work.

Повну модель описано в матеріалі private networking і internal domains.

Як збої Redis мають впливати на застосунок?

Класифікуйте робоче навантаження до того, як писати recovery code.

Робоче навантаження	Допустимість втрати	Реакція під час збою
HTML fragment cache	Висока	Відновити з джерела
Session store	Низька або середня	Можливо, користувачів буде розлогінено; спроєктувати fallback
Rate-limit counters	Залежить від політики	Явно визначити fail open або fail closed
Job queue	Низька	Припинити приймати завдання або зберігати їх в іншому місці
Distributed lock	Дуже низька для критичних секцій	Використовувати fencing/idempotency
Feature cache	Висока	Використовувати значення за замовчуванням або джерело

Cache client не має повторювати запити безкінечно. Тривалі retry можуть зайняти всіх worker-ів застосунку й перетворити інцидент Redis на повну відмову сервісу. Queue workers мають застосовувати backoff, показувати помилкові завдання й зупинятися відповідно до визначеної policy.

Перевірте розмір Redis і runtime logs застосунку, який його використовує:

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

Зростання розміру може свідчити про відсутність expiration, неконтрольоване зростання queue depth, надто великі payloads або покинуті namespaces. Не вважайте restart бази даних першою реакцією на timeouts застосунку: спочатку перевірте configuration, networking і поведінку client.

Як backup, migration і monitoring пов’язані з Redis?

Dockup надає workflow для backup керованої бази даних:

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

Чи відповідає backup Redis цілям відновлення робочого навантаження, залежить від значення даних. Backup cache може бути непотрібним. Backup queue усе одно може втратити завдання, прийняті після моменту створення backup. Критично важливі job-и за можливості мають мати відновлюваний source record поза queue.

Перемістіть Redis між nodes за допомогою:

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

Заплануйте вплив migration на clients і workers. До початку роботи в production переконайтеся, що reconnection, retry та idempotency працюють належним чином.

Окрім розміру бази даних, моніторте metrics на рівні застосунку:

• Cache hit ratio.
• Miss latency.
• Evictions.
• Queue depth і вік найстарішого job.
• Кількість успішних job, retry і помилок.
• Worker concurrency.
• Redis connection errors.
• Payload size.

Dockup щохвилини вимірює споживання CPU, RAM і disk відповідно до балансу plan. Рекомендований Pro plan коштує $20 на місяць і містить $20 usage credit, але рішення щодо capacity мають ґрунтуватися на metrics робочого навантаження, а не на назві plan.

Який production checklist для Redis є безпечним?

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

1. Точну ціль project/db.
2. Задокументовані обов’язки cache і queue.
3. Connection URL замасковано як secret.
4. Визначено policy private networking.
5. Для кожного cache налаштовано TTL або явну інвалідацію.
6. Queue workers є idempotent.
7. Retry і dead-letter поведінку визначено queue system.
8. Налаштовано alerts для size і queue depth.
9. Зрозуміло цінність і обмеження backup.
10. Restart і migration потребують approval.

Приклад розділення cache і queue

Невеликий застосунок може почати з однієї Redis database, якщо ризик низький, але використовуйте зрозумілі key prefixes:

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

У міру зростання навантаження відокремлюйте критичний queue state від cache state, для якого активно застосовується eviction. Це операційна межа, а не просто питання naming.

Успішний дизайн Redis cache і queue робить поведінку застосунку передбачуваною, коли Redis працює швидко, повільно, повертає порожні результати або недоступний.

Операції з реляційним source of truth описано в матеріалі керований PostgreSQL. Про ширший вибір capacity читайте в матеріалі стратегії масштабування баз даних. Актуальні команди для роботи з базами даних наведено в довіднику Dockup CLI.

Визначайте еволюцію keys і payloads

Cache і queue data переживають один процес застосунку. Під час blue-green cutover новий release може читати keys, записані попереднім release. Версіонуйте key namespaces і job payloads, щоб обидві версії могли працювати паралельно.

Для queue додавайте payload version і підтримуйте у workers обробку щонайменше тих версій, які все ще можуть очікувати у queue. Rollback deployment може повернути старий code, тоді як jobs у новому форматі залишаться в Redis. Без compatibility rollback застосунку може збільшити кількість помилок.

Навмисно тестуйте resource pressure

У non-production environment перевірте відсутні keys, повільні відповіді Redis, connection resets, queue backlog, duplicate delivery і стан повної або майже повної пам’яті. Спостерігайте, чи застосунок використовує fail open, fail closed, retry або перевантажує іншу dependency.

Runbook для Redis cache і queue має встановлювати обмеження на кількість retry та concurrency. Необмежені retry loops можуть зайняти всіх workers і ускладнити відновлення сильніше, ніж початковий інцидент.

Зберігайте recovery path до source of truth

Для критичних jobs зберігайте в primary database достатньо state, щоб відновити роботу після втрати Redis. Queue має прискорювати обробку, а не бути єдиним записом про те, що дія користувача відбулася.

Починайте з deployment, який можна перевірити

Створіть Redis у non-production проєкті, протестуйте cache fallback і duplicate job delivery та явно визначте failure policy до того, як передавати йому критичну роботу.

Почніть безкоштовно на app.dockup.ai. Free plan коштує $0 на місяць, містить стартовий credit $10 і підтримує один workspace, три databases і три deployments.

FAQ

Чи може Dockup створити керований Redis?

Так. Використайте команду створення керованої бази даних із типом redis, а потім підключіть застосунок за допомогою отриманих connection material, збережених як secret.

Чи варто зберігати cache і queue data в одному Redis instance?

Для невеликого робочого навантаження з низьким ризиком це можливо, але розділення безпечніше, коли eviction cache та критичне зберігання queue мають різні вимоги до доступності й пам’яті.

Чи гарантує Redis, що queued job виконається рівно один раз?

Не слід припускати наявність загальної гарантії exactly-once. Семантика доставки залежить від бібліотеки queue та дизайну worker, тому side effects мають бути idempotent.

Чи може Redis використовувати Dockup private networking?

Так. Увімкніть мережу проєкту, повторно розгорніть services, які використовують Redis, щоб отримати internal variables, і за потреби зробіть Redis database доступною лише приватно.

Чи достатньо backup Redis для критично важливої job queue?

Не обов’язково. Backup відповідає певному моменту часу й може не містити новіші прийняті jobs. Зберігайте відновлювані source records і визначте recovery jobs на рівні застосунку.