Redis — cache w pamięci dla stron i sklepów
Redis to warstwa szybkości stojąca za stronami, sklepami i marketplace'ami budowanymi na 4buildsite: trzyma w pamięci (RAM) dokładnie te dane, które trzeba podawać często — strony z cache'a, sesje, koszyki, limity żądań — i odpowiada w mniej niż milisekundę. Źródłem prawdy pozostaje PostgreSQL; Redis chroni go przy dużym ruchu. Jest wliczony i zarządzany przez platformę, bez żadnej konfiguracji z Twojej strony.
Czym jest Redis i dlaczego jest tak szybki
Redis (REmote DIctionary Server) to otwartoźródłowa baza danych działająca w pamięci: trzyma dane w RAM-ie, a nie na dysku, więc odpowiada w mniej niż milisekundę. Na 4buildsite używamy go jako warstwy przed PostgreSQL — do wszystkiego, co musi być podawane często: stron, sesji, koszyków i limitów żądań.
W odróżnieniu od dysku RAM jest szybszy o rzędy wielkości, a Redis dokłada natywne struktury danych (ciąg znaków, hasz, lista, zbiór, zbiór posortowany, strumień), które pozwalają wykonywać złożone operacje bezpośrednio w pamięci, bez wędrówki do głównej bazy. Polecenia przetwarzane są jednowątkowo, więc zachowanie systemu jest przewidywalne i wolne od wyścigów.
- Typowe opóźnienie poniżej 1 ms i ponad 100 000 operacji na sekundę na jednym węźle
- Struktury natywne: hasze do sesji, zbiory posortowane do rankingów i ograniczania liczby żądań, strumienie do kolejek
- Jednowątkowe przetwarzanie poleceń → przewidywalne zachowanie, bez złożonych blokad
Cache: Twoje strony i dane podawane z pamięci
Strategia to cache-aside: pierwsze żądanie czyta z PostgreSQL i zapisuje wynik w Redisie z TTL (czasem życia); kolejne żądania biorą go wprost z pamięci. Gdy edytujesz stronę, klucz jest jawnie usuwany — nigdy nie podajemy nieaktualnych danych przez ślepy TTL.
Dla strony wizytówki albo sklepu oznacza to, że listy produktów, menu, popularne podstrony i fragmenty treści są czytane z pamięci, a nie z bazy danych, także przy dużym ruchu. W szczytach (kampania, Black Friday) Redis pochłania powtarzalne żądania i odciąża bazę danych.
- Cache-aside z jawną inwalidacją — bez nieaktualnych danych
- Zapamiętuje fragmenty stron i wyniki zapytań, nie tylko całe strony
- Chroni PostgreSQL w szczytach ruchu, czytając powtarzalne dane z pamięci
Sesje, koszyk zakupowy i ochrona przed nadużyciami
Sesje użytkowników i tokeny odświeżające trzymane są w Redisie: uwierzytelnianie, automatyczne wygasanie przez TTL i unieważnienie na wszystkich urządzeniach, gdy ktoś się wyloguje albo zmieni hasło.
Koszyk zakupowy w sklepach budowanych na 4buildsite trzymany jest w Redisie dla niezalogowanych odwiedzających — z wygasaniem i bez rozdymania głównej bazy. To również Redis stosuje ograniczanie liczby żądań na formularzach kontaktowych i przy logowaniu, korzystając ze zbiorów posortowanych, aby zatrzymać spam i próby siłowego łamania haseł, zanim dotrą do bazy danych.
- Magazyn sesji z automatycznym wygasaniem i wybiórczym unieważnianiem tokenów
- Trwały koszyk z TTL dla anonimowych odwiedzających
- Ograniczanie liczby żądań i ochrona przed nadużyciami na formularzach i przy logowaniu
Czas rzeczywisty i kolejki zadań w tle
Redisowe Pub/Sub i strumienie zasilają aktualizacje w czasie rzeczywistym: spadający na żywo stan magazynowy, powiadomienie w aplikacji, zmieniający się status zamówienia — wszystko bez odświeżania strony przez odwiedzającego i bez powtarzalnego odpytywania, które męczy serwer.
Ciężkie zadania (przetworzenie obrazu, wygenerowanie eksportu, synchronizacja) trafiają do kolejki Redisa i wykonują je procesy robocze w tle, żeby odwiedzający nie czekał na jej wykonanie. Mechanizm rozproszonych blokad gwarantuje, że krytyczna operacja nie wykona się dwa razy.
- Pub/Sub i strumienie do zdarzeń na żywo (stany magazynowe, zamówienia, powiadomienia)
- Kolejki zadań do ciężkich obliczeń wykonywanych asynchronicznie
- Rozproszone blokady dla operacji, które nie mogą wykonać się dwukrotnie
Zalety i ograniczenia
Zalety
- Odpowiedź poniżej 1 ms: dane z cache'a czytane są bezpośrednio z pamięci
- Radykalnie zmniejsza obciążenie PostgreSQL przy dużym ruchu
- Natywne struktury do sesji, koszyka, ograniczania liczby żądań i rankingów
- Pub/Sub i strumienie do funkcji czasu rzeczywistego, bez odpytywania
- Kolejki zadań do ciężkich obliczeń, bez zatrzymywania odwiedzającego
- Wliczony i zarządzany przez platformę — zero konfiguracji po Twojej stronie
Ograniczenia
- Dane leżą w RAM-ie, droższym niż dysk → to nie jest rozwiązanie do ogromnych zbiorów rzadko używanych danych
- To cache, warstwa pomocnicza, a nie źródło prawdy — dane trwałe zostają w PostgreSQL
- Trwałość danych (RDB/AOF) zmniejsza, ale nie usuwa całkowicie ryzyka utraty ostatnich sekund przy awarii
- Wymaga poprawnej strategii inwalidacji, inaczej może podawać nieaktualne dane
Krótki werdykt
Używaj Redisa do wszystkiego, co musi być natychmiastowe — cache'a, sesji, koszyka, ograniczania liczby żądań, czasu rzeczywistego i kolejek zadań. Nie stosuj go jako głównego magazynu danych; do tego służy PostgreSQL. Na 4buildsite masz oba, dobrane automatycznie: nie musisz nic wybierać ani konfigurować.
Tabela specyfikacji
| Możliwość | Szczegół | Gdzie używane w kreatorze |
|---|---|---|
| Opóźnienie | < 1 ms (w pamięci) | Strony i dane czytane z pamięci |
| Przepustowość | > 100 000 operacji na sekundę na węzeł | Duży ruch z odciążeniem bazy |
| Struktury danych | ciąg znaków, hasz, lista, zbiór, zbiór posortowany, strumień | Sesje, koszyk, rankingi, kolejki, ograniczanie liczby żądań |
| Trwałość danych | Migawka RDB i dziennik AOF | Szybkie odtworzenie po restarcie |
| Wygasanie | TTL dla każdego klucza | Koszyk, sesje i cache z automatycznym czyszczeniem |
| Czas rzeczywisty | Pub/Sub i strumienie | Stany magazynowe na żywo, powiadomienia, status zamówienia |
Redis (cache) a sama baza danych
| Kryterium | Z Redisem | Sam PostgreSQL |
|---|---|---|
| Czas odpowiedzi przy powtarzalnych danych | poniżej 1 ms, z pamięci | dziesiątki ms, zapytanie przy każdym żądaniu |
| Przy dużym ruchu | baza chroniona, łatwo się skaluje | baza się zatyka, grożą przekroczenia limitu czasu |
| Koszyk i sesje | szybkie, z automatycznym wygasaniem | rosnące tabele obciążające bazę |
| Czas rzeczywisty | natywne Pub/Sub i strumienie | powtarzalne odpytywanie, kosztowne |
| Kolejki zadań | natywne, proste w użyciu | rozwiązania prowizoryczne albo żadne |
Najczęstsze pytania
Czym jest Redis w skrócie?
Bardzo szybką bazą danych działającą w pamięci, używaną jako warstwa cache'a, sesji i czasu rzeczywistego przed główną bazą. Odpowiada w mniej niż milisekundę i odciąża główną bazę przy dużym ruchu.
Dlaczego nie wystarczy sam PostgreSQL?
PostgreSQL jest źródłem prawdy (dane trwałe), ale Redis podaje powtarzalne dane w mniej niż milisekundę i przejmuje koszyk, sesje, ograniczanie liczby żądań oraz czas rzeczywisty, chroniąc bazę przy dużym ruchu. Oba rozwiązania pracują razem.
Czy stracę dane, jeśli Redis padnie?
Nie treści strony: dane trwałe są w PostgreSQL. W Redisie znajdują się tylko cache i dane tymczasowe, a trwałość RDB/AOF ogranicza straty. Restart Redisa nie wpływa na Twoją opublikowaną stronę.
Czy muszę samodzielnie konfigurować Redisa?
Nie. Jest wliczony i zarządzany przez platformę 4buildsite; korzystasz z funkcji czasu rzeczywistego, nie administrując niczym.
Jak Redis pomaga sklepowi internetowemu?
Szybki koszyk dla odwiedzających, listy produktów w cache'u, stany magazynowe aktualizowane na żywo oraz ochrona przed nadużyciami przy finalizacji zamówienia i na formularzach — wszystko bez obciążania bazy danych.
Czy Redis pomaga w SEO i Core Web Vitals?
Tak, pośrednio: czas odpowiedzi serwera wpływa na TTFB, a ten na Core Web Vitals — sygnały istotne dla Google'a i dla doświadczenia użytkownika.