Obciążenia cache i kolejek Redis w Dockup

Obciążenia cache i kolejek Redis mogą korzystać z tej samej zarządzanej usługi Redis, ale mają różne wymagania dotyczące poprawności działania. Cache zazwyczaj można odbudować po utracie danych. Kolejka może natomiast reprezentować zadania, których nie wolno po cichu odrzucić ani przetworzyć dwukrotnie.

Dockup udostępnia Redis jako zarządzaną bazę danych, oferuje operacje związane z rozmiarem i logami, obsługuje procesy backupu i migracji węzłów oraz umożliwia łączenie bazy danych z usługami aplikacji przez prywatną sieć projektu.

Jak utworzyć zarządzanego Redis?

Utwórz Redis w wybranym workspace:

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

Potwierdź docelową bazę danych:

dockup db list --json

Przechowuj zwrócone dane połączenia poza systemem kontroli wersji i podłącz je do usługi korzystającej z bazy jako secret:

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

dockup deploy production/api --wait --json

Ponowne wdrożenie tworzy nowy kontener aplikacji ze zaktualizowanym środowiskiem. Restart starego kontenera nie zastosuje nowo zapisanej wartości docelowej.

Korzystaj z oddzielnych baz danych lub instancji Redis, gdy zachowanie związane z usuwaniem elementów z cache oraz wymagana retencja krytycznej kolejki nie powinny konkurować o tę samą pamięć. Izolacja upraszcza również diagnozowanie incydentów i kontrolę dostępu.

Kiedy używać Redis jako cache?

Cache ogranicza powtarzalną pracę lub opóźnienia, przechowując dane pochodne. Źródło prawdy pozostaje w innym miejscu — zwykle w PostgreSQL, MySQL, MongoDB, zewnętrznym API albo w wyniku deterministycznych obliczeń.

Dobrze zaprojektowany cache definiuje:

• Format klucza cache i namespace.
• Time to live.
• Maksymalny akceptowalny poziom nieaktualności danych.
• Wyzwalacz unieważnienia.
• Zachowanie w przypadku cache miss.
• Zachowanie, gdy Redis jest niedostępny.
• Ochronę przed thundering herd.
• Dane, których nigdy nie wolno umieszczać w cache.

Awaria	Bezpieczne zachowanie cache
Brak klucza	Ponownie oblicz dane lub odczytaj źródło prawdy
Redis niedostępny	Przełącz się na źródło z ochroną rate limiting
Nieaktualny wpis	Usuń po wygaśnięciu lub unieważnij
Zmiana serializacji	Wersjonuj namespace kluczy
Presja na pamięć	W pierwszej kolejności usuwaj dane możliwe do odbudowania
Hot key	Dodaj lokalny cache, sharding lub request coalescing

Nie uzależniaj dostępności całej aplikacji wyłącznie od opcjonalnego cache. Stosuj ograniczone timeouty i ścieżki fallback. Z drugiej strony nie ukrywaj wszystkich awarii — długotrwała niedostępność cache może przeciążyć źródłową bazę danych.

Co się zmienia, gdy Redis służy jako kolejka zadań?

Kolejka reprezentuje oczekujące zadania, dlatego aplikacja musi definiować semantykę dostarczania i odzyskiwania zadań. Redis sam w sobie jest serwerem struktur danych; gwarancje zależą od biblioteki kolejki i protokołu workera.

Określ:

1. Kiedy zadanie uznaje się za przyjęte?
2. Kiedy jest potwierdzane?
3. Co się dzieje, jeśli worker ulegnie awarii po wykonaniu efektu ubocznego, ale przed potwierdzeniem?
4. Jak opóźnia się ponowienia i ustala ich limit?
5. Dokąd trafiają zadania, które zakończyły się trwałym błędem?
6. Jak zapewnić bezpieczeństwo wielokrotnego wykonania?
7. Jak monitorować długość kolejki?
8. Czy można odtworzyć payload zadania?

Twórz idempotentne workery. Przechwycenie płatności, wysłanie wiadomości e-mail lub import danych może po awarii zostać dostarczone więcej niż raz. Używaj biznesowego klucza idempotencji i zapisuj ukończenie operacji w bazie danych będącej źródłem prawdy.

Rozdzielaj nazwy kolejek według obciążenia i priorytetu. Powolne zadanie związane z multimediami nie powinno blokować przetwarzania resetów haseł ani webhooków. Unikaj umieszczania sekretów w payloadach zadań, jeśli wystarczy identyfikator referencyjny.

Wdrożenie cache i kolejki Redis powinno dokumentować, które klucze można usunąć, a które reprezentują pracę biznesową.

Jak prywatna sieć łączy usługi z Redis?

Włącz sieć projektu:

dockup network enable production --json

Usługa Redis stanie się dostępna pod stabilnym hostname <slug>.internal z usług należących do tego samego projektu. Wykonaj ponowne wdrożenie aplikacji, aby Dockup mógł wstrzyknąć wewnętrzne zmienne połączeniowe.

Aby udostępnić Redis wyłącznie prywatnie:

dockup db private production/app-redis --json

Przywróć publiczny listener, gdy jest to wymagane:

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

Prywatna sieć usuwa publiczną ścieżkę internetową dla ruchu wewnątrz tego samego projektu, ale nie zastępuje uwierzytelniania. Przechowuj dane połączenia Redis jako secret i ogranicz liczbę usług, które je otrzymują.

Różne projekty nie mogą uzyskiwać dostępu do swoich prywatnych sieci. Ta granica może być przydatna, gdy produkcja i staging nie powinny współdzielić kluczy cache ani zadań z kolejek.

Pełny model opisano w artykule prywatne sieci i domeny wewnętrzne.

Jak awarie Redis powinny wpływać na aplikację?

Przed napisaniem kodu odpowiedzialnego za odzyskiwanie danych sklasyfikuj obciążenie.

Obciążenie	Tolerancja utraty	Reakcja na awarię
Cache fragmentów HTML	Wysoka	Odbuduj dane ze źródła
Store sesji	Niska do średniej	Użytkownicy mogą zostać wylogowani; zaprojektuj fallback
Liczniki rate limitingu	Zależna od polityki	Jawnie zdecyduj, czy fail open, czy fail closed
Kolejka zadań	Niska	Przestań przyjmować zadania lub utrwalaj je gdzie indziej
Distributed lock	Bardzo niska w krytycznych sekcjach	Użyj fencing/idempotency
Cache funkcji	Wysoka	Użyj wartości domyślnej lub źródła

Klient cache nie powinien ponawiać prób w nieskończoność. Długie retry mogą zająć wszystkie workery aplikacji i zmienić incydent Redis w pełną awarię. Workery kolejek powinny stosować backoff, udostępniać informacje o nieudanych zadaniach i zatrzymywać się zgodnie z określoną polityką.

Sprawdź rozmiar Redis oraz logi runtime aplikacji:

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

Wzrost rozmiaru może wskazywać na brak expiration, niekontrolowany wzrost kolejki, zbyt duże payloady lub porzucone namespace’y. Nie traktuj restartu bazy danych jako pierwszej reakcji na timeouty aplikacji; najpierw sprawdź konfigurację, sieć i zachowanie klienta.

Jak backup, migracja i monitoring współdziałają z Redis?

Dockup udostępnia workflow backupu zarządzanej bazy danych:

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

To, czy backup Redis spełnia cel odzyskiwania dla danego obciążenia, zależy od znaczenia przechowywanych danych. Backup cache może być niepotrzebny. Backup kolejki może nadal oznaczać utratę zadań przyjętych po jego utworzeniu. Jeśli to możliwe, krytyczne zadania biznesowe powinny mieć możliwy do odzyskania rekord źródłowy poza kolejką.

Przenieś Redis między węzłami za pomocą:

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

Zaplanuj wpływ migracji na klientów i workery. Przed wdrożeniem na produkcję potwierdź, że ponowne połączenia, retry i idempotency działają poprawnie.

Oprócz rozmiaru bazy monitoruj metryki na poziomie aplikacji:

• Współczynnik cache hit.
• Opóźnienie cache miss.
• Evictions.
• Długość kolejki i wiek najstarszego zadania.
• Liczba zadań zakończonych powodzeniem, ponowień i błędów.
• Concurrency workerów.
• Błędy połączeń Redis.
• Rozmiar payloadów.

Dockup mierzy zużycie CPU, RAM i dysku co minutę w odniesieniu do limitów planu. Rekomendowany plan Pro kosztuje 20 USD miesięcznie i obejmuje 20 USD kredytu na użycie, ale decyzje dotyczące capacity powinny wynikać z metryk obciążenia, a nie z nazwy planu.

Jaka jest bezpieczna checklista produkcyjna Redis?

Przed uruchomieniem zweryfikuj:

1. Dokładny target project/db.
2. Udokumentowane role cache i kolejki.
3. URL połączenia jako zamaskowany secret.
4. Ustaloną politykę prywatnej sieci.
5. TTL lub jawne unieważnianie dla każdego cache.
6. Idempotentność workerów kolejek.
7. Zdefiniowane przez system kolejkowy zasady retry i dead-letter.
8. Istnienie alertów dotyczących rozmiaru i długości kolejki.
9. Zrozumienie wartości i ograniczeń backupu.
10. Restart i migrację wymagające zatwierdzenia.

Przykład rozdzielenia cache i kolejki

Mała aplikacja może rozpocząć pracę z jedną bazą Redis, gdy ryzyko jest niskie, ale powinna używać przejrzystych prefixów kluczy:

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

Wraz ze wzrostem obciążenia rozdziel krytyczny stan kolejki od agresywnie czyszczonego stanu cache. To granica operacyjna, a nie tylko kwestia nazewnictwa.

Udany projekt cache i kolejki Redis sprawia, że zachowanie aplikacji jest przewidywalne, gdy Redis działa szybko, wolno, jest pusty lub niedostępny.

Informacje o operacjach na relacyjnych źródłach prawdy znajdziesz w artykule zarządzany PostgreSQL. Szersze omówienie wyboru capacity znajdziesz w artykule strategie skalowania baz danych. Aktualne polecenia dotyczące baz danych znajdziesz w dokumentacji Dockup CLI.

Zdefiniuj ewolucję kluczy i payloadów

Dane cache i kolejek mogą przetrwać pojedynczy proces aplikacji. Nowa wersja może odczytywać klucze zapisane przez poprzednią wersję podczas przełączania blue-green. Wersjonuj namespace’y kluczy i payloady zadań, aby obie wersje mogły współistnieć.

W przypadku kolejek dodaj wersję payloadu i zapewnij workerom możliwość przetwarzania co najmniej tych wersji, które mogą nadal oczekiwać w kolejce. Rollback wdrożenia może przywrócić stary kod, gdy zadania w nowym formacie pozostaną w Redis. Bez kompatybilności rollback aplikacji może zwiększyć liczbę błędów.

Celowo testuj presję na zasoby

W środowisku innym niż produkcyjne przetestuj brakujące klucze, powolne odpowiedzi Redis, resetowanie połączeń, narastanie kolejki, wielokrotne dostarczanie zadań oraz pełną lub niemal pełną pamięć. Sprawdź, czy aplikacja stosuje fail open, fail closed, retry lub przeciąża inną zależność.

Runbook cache i kolejki Redis powinien określać limity prób ponowienia i concurrency. Nieograniczone pętle retry mogą zająć wszystkie workery i utrudnić odzyskiwanie po awarii bardziej niż sam pierwotny incydent.

Zachowaj ścieżkę odzyskiwania ze źródła prawdy

W przypadku krytycznych zadań przechowuj w głównej bazie danych wystarczający stan, aby można było odtworzyć pracę po utracie Redis. Kolejka powinna przyspieszać przetwarzanie, a nie stawać się jedynym zapisem potwierdzającym wykonanie działania przez klienta.

Zacznij od możliwego do zweryfikowania wdrożenia

Utwórz Redis w projekcie innym niż produkcyjny, przetestuj fallback cache oraz wielokrotne dostarczanie zadań i jawnie określ politykę awarii przed przekierowaniem krytycznych zadań.

Zacznij bezpłatnie na app.dockup.ai. Plan Free kosztuje 0 USD miesięcznie, obejmuje 10 USD początkowego kredytu i obsługuje jeden workspace, trzy bazy danych oraz trzy wdrożenia.

FAQ

Czy Dockup może utworzyć zarządzanego Redis?

Tak. Użyj polecenia tworzenia zarządzanej bazy danych z typem redis, a następnie połącz aplikację, korzystając ze zwróconych danych połączenia zapisanych jako secret.

Czy dane cache i kolejki powinny współdzielić jedną instancję Redis?

W przypadku małego obciążenia o niskim ryzyku jest to możliwe, ale rozdzielenie jest bezpieczniejsze, gdy usuwanie elementów cache oraz retencja krytycznej kolejki mają różne wymagania dotyczące dostępności i pamięci.

Czy Redis gwarantuje, że zadanie z kolejki zostanie wykonane dokładnie raz?

Nie należy zakładać ogólnej gwarancji wykonania dokładnie raz. Semantyka dostarczania zależy od biblioteki kolejki i projektu workera, dlatego efekty uboczne powinny być idempotentne.

Czy Redis może korzystać z prywatnej sieci Dockup?

Tak. Włącz sieć projektu, wykonaj ponowne wdrożenie usług korzystających z bazy, aby otrzymać zmienne wewnętrzne, i opcjonalnie ustaw bazę Redis jako dostępną wyłącznie prywatnie.

Czy backup Redis wystarczy w przypadku krytycznej kolejki zadań?

Niekoniecznie. Backup przedstawia stan z określonego momentu i może nie zawierać nowszych przyjętych zadań. Zachowuj możliwe do odzyskania rekordy źródłowe i definiuj odzyskiwanie zadań na poziomie aplikacji.