Redis – baza in-memory do cache i kolejek

geek.justjoin.it 4 dni temu

Twoja aplikacja działa świetnie na środowisku testowym. Potem przychodzi ruch z produkcji, baza danych zaczyna się dławić, a czas odpowiedzi rośnie z 80 ms do kilku sekund. Zanim zaczniesz skalować PostgreSQL czy MySQL, warto zadać sobie jedno pytanie: czy każde zapytanie naprawdę musi trafiać do dysku?

Tu wchodzi Redis – baza danych trzymająca dane w pamięci RAM, która odpowiada w ułamkach milisekundy. Używają jej start-upy i korporacje, a w polskich zespołach backendowych to jedno z pierwszych narzędzi, po które sięgasz przy problemach z wydajnością. W tym artykule wyjaśniamy, czym jest Redis, jak go używać jako cache i kolejki, kiedy się sprawdza, a kiedy nie, oraz jak wypada w porównaniu z Memcached. Znajdziesz tu też krótki tutorial z kodem.

Redis – co to jest?

Redis (od REmote DIctionary Server) to baza danych typu klucz–wartość, która przechowuje dane głównie w pamięci operacyjnej. Stworzył ją w 2009 roku Salvatore Sanfilippo (znany jako antirez), a dziś rozwija ją firma Redis Ltd. wraz ze społecznością.

Najczęściej opisuje się go jako bazę in-memory, ale to uproszczenie. Redis to raczej serwer struktur danych. Oprócz zwykłych tekstów obsługuje m.in.:

Stringi – podstawowy typ, od prostych wartości po liczniki (INCR),
Listy – kolejki i stosy (LPUSH, RPOP, BLPOP),
Zbiory (sets) – unikalne elementy, operacje sumy i przecięcia,
Zbiory posortowane (sorted sets) – elementy z wynikiem, idealne do rankingów,
Hashe – obiekty z polami, np. profil użytkownika,
Streamy – log zdarzeń z grupami konsumentów,
Bitmapy, HyperLogLog i indeksy geograficzne – do zliczania, estymacji i zapytań o lokalizację.

W nowszych wersjach dochodzą też typy znane wcześniej z modułów, m.in. JSON, wyszukiwanie pełnotekstowe oraz wyszukiwanie wektorowe, które zyskało na znaczeniu wraz z rozwojem AI (np. przy RAG i semantycznym cache dla zapytań do LLM-ów).

Dlaczego Redis jest tak szybki?

Szybkość wynika z kilku decyzji projektowych:

Dane w RAM – dostęp do pamięci jest o rzędy wielkości szybszy niż do dysku, choćby SSD.
Prosty protokół (RESP) i lekkie struktury danych zaprojektowane pod konkretne operacje.
Jednowątkowe wykonywanie komend – brak blokad i przełączania kontekstu przy samych operacjach na danych. Od wersji 6.0 Redis korzysta dodatkowo z wątków I/O do obsługi sieci.
Multipleksowanie I/O (epoll/kqueue), za pomocą którego jeden proces obsługuje tysiące połączeń.

W praktyce pojedyncza instancja obsługuje setki tysięcy operacji na sekundę, a typowe opóźnienia mieszczą się poniżej milisekundy. Konkretne wyniki zależą od sprzętu, sieci i rozmiaru danych, więc zawsze mierz je na własnym środowisku (np. narzędziem redis-benchmark).

Czy Redis zapisuje dane na dysk?

Tak. To częsty mit, iż Redis „gubi wszystko po restarcie”. Masz do wyboru dwa mechanizmy trwałości:

RDB (snapshoty) – okresowy zapis stanu bazy do pliku. Jest szybki i kompaktowy, ale przy awarii tracisz dane od ostatniego snapshotu.
AOF (Append Only File) – log każdej operacji zapisu. Możesz go synchronizować co sekundę lub przy każdej komendzie, kosztem wydajności.

W wielu wdrożeniach łączy się oba podejścia. jeżeli Redis służy wyłącznie jako cache, możesz trwałość wyłączyć i traktować dane jako odtwarzalne.

Redis – tutorial: pierwsze kroki

Najszybszy sposób na start to Docker. Poniższy przykład uruchamia lokalną instancję i otwiera klienta wiersza poleceń:

docker run -d --name redis -p 6379:6379 redis:latest docker exec -it redis redis-cli

Na produkcji przypnij konkretną wersję obrazu zamiast latest.

Podstawowe komendy w redis-cli

SET user:1:name "Anna" GET user:1:name SET sesja:abc123 "dane" EX 3600 # wygasa po 3600 sekundach TTL sesja:abc123 INCR licznik:odwiedzin HSET user:1 imie "Anna" miasto "Kraków" HGETALL user:1 ZADD ranking 1500 "gracz1" 1800 "gracz2" ZREVRANGE ranking 0 2 WITHSCORES

Zwróć uwagę na konwencję nazewnictwa kluczy: typ:id:pole. Dwukropek jest umowny, ale wszyscy go stosują. Dzięki temu łatwiej przeglądać i czyścić dane.

Redis z poziomu kodu (Python)

import redis r = redis.Redis(host="localhost", port=6379, decode_responses=True) r.set("user:1:name", "Anna", ex=60) print(r.get("user:1:name")) # Anna

Podobne biblioteki znajdziesz w każdym popularnym języku: ioredis i node-redis dla Node.js, Jedis i Lettuce dla Javy, go-redis dla Go, StackExchange.Redis dla .NET.

Redis cache – najpopularniejsze zastosowanie

Większość zespołów zaczyna przygodę z Redisem właśnie od cache. Idea jest prosta: kosztowny wynik (zapytanie SQL, odpowiedź zewnętrznego API, wyrenderowany fragment strony) zapisujesz na chwilę w pamięci i serwujesz kolejnym użytkownikom bez ponownego liczenia.

Wzorzec cache-aside

Najczęściej stosowany wzorzec wygląda tak:

Aplikacja sprawdza, czy dane są w Redisie.
Jeśli tak (cache hit) – zwraca je od razu.
Jeśli nie (cache miss) – pobiera je z bazy, zapisuje w Redisie z TTL i zwraca użytkownikowi.

def get_user(user_id): key = f"user:{user_id}" cached = r.get(key) if cached: return json.loads(cached) user = db.query_user(user_id) # wolne zapytanie r.set(key, json.dumps(user), ex=300) # TTL 5 minut return user

Inne wzorce to write-through (zapis jednocześnie do cache i bazy), write-behind (zapis do cache, a do bazy asynchronicznie) oraz read-through (cache sam pobiera brakujące dane). Cache-aside jest najprostszy i daje największą kontrolę, dlatego wygrywa w większości projektów.

TTL i polityki wypychania danych

Pamięć RAM jest droga i ograniczona, więc musisz zdecydować, co się stanie, gdy się skończy. Parametr maxmemory ustawia limit, a maxmemory-policy określa strategię. Najczęściej spotkasz:

allkeys-lru – usuwa najdawniej używane klucze spośród wszystkich (dobry domyślny wybór dla cache),
allkeys-lfu – usuwa najrzadziej używane,
volatile-lru / volatile-ttl – ruszają tylko klucze z ustawionym TTL,
noeviction – odrzuca zapisy, gdy brakuje pamięci (sensowne, gdy Redis przechowuje dane, których nie wolno stracić).

Najczęstsze błędy przy cache

Brak TTL – klucze rosną w nieskończoność, aż pamięć się skończy.
Cache stampede – gdy popularny klucz wygasa, setki żądań naraz uderzają w bazę. Pomagają losowy jitter w TTL, blokady na czas odbudowy cache lub odświeżanie z wyprzedzeniem.
Nieaktualne dane – zapomniana inwalidacja po zmianie rekordu. Pamiętaj o słynnym żarcie, iż w informatyce są tylko dwa trudne problemy: nazywanie rzeczy i unieważnianie cache.
Zbyt duże wartości – wielomegabajtowe klucze blokują jednowątkowy serwer i zwiększają opóźnienia innych klientów.
Komenda KEYS * na produkcji – skanuje całą bazę. Używaj SCAN.

Redis jako kolejka i broker wiadomości

Redis świetnie radzi sobie nie tylko z cache. Wiele zespołów używa go także do kolejek zadań i komunikacji między usługami. Masz tu trzy główne opcje.

Listy

Najprostsza kolejka: producent robi LPUSH, a worker BRPOP, czyli blokujące pobranie z limitem czasu. Działa dobrze, ale brakuje potwierdzeń przetworzenia. jeżeli worker padnie w trakcie zadania, wiadomość przepada (chyba iż użyjesz wzorca z kolejką pomocniczą i LMOVE).

Pub/Sub

Mechanizm „wyślij i zapomnij”. Subskrybenci dostają wiadomości w czasie rzeczywistym, ale tylko jeżeli są w danej chwili podłączeni. Nic nie jest zapisywane. Sprawdza się w powiadomieniach na żywo i czatach, gdzie utrata wiadomości nie jest tragedią.

Streamy

Redis Streams to najbardziej dojrzałe rozwiązanie. Wiadomości trafiają do logu, a grupy konsumentów (XGROUP, XREADGROUP) pozwalają rozdzielać pracę między wielu workerów. Każda wiadomość wymaga potwierdzenia (XACK), więc nieprzetworzone zadania możesz odzyskać. To podejście przypomina uproszczoną wersję Kafki, choć w mniejszej skali i bez jej ekosystemu.

Gotowe biblioteki kolejek

W praktyce rzadko piszesz wszystko od zera. Redis jest fundamentem wielu popularnych narzędzi:

Sidekiq (Ruby),
BullMQ (Node.js),
Celery i RQ (Python),
Asynq (Go).

Jeśli potrzebujesz złożonego routingu, gwarancji dostarczenia na dużą skalę lub wielodniowej retencji zdarzeń, rozważ RabbitMQ albo Kafkę. Redis wygrywa prostotą i szybkością wdrożenia.

Redis – zastosowania w praktyce

Poza cache i kolejkami Redis pojawia się w wielu miejscach architektury:

Sesje użytkowników – szybki dostęp i automatyczne wygasanie dzięki TTL. Dzięki temu aplikacja może być bezstanowa i skalować się poziomo.
Rate limiting – licznik z INCR i EXPIRE ogranicza liczbę żądań na użytkownika lub adres IP.
Rankingi i leaderboardy – sorted sets dają pozycję gracza w czasie O(log N).
Liczniki w czasie rzeczywistym – wyświetlenia, polubienia, aktywni użytkownicy (HyperLogLog zlicza unikaty, zużywając kilka pamięci).
Blokady rozproszone – wzorzec SET klucz wartość NX PX czas. Uważaj jednak: algorytm Redlock budzi spory ekspertów (m.in. Martin Kleppmann i antirez), więc przy krytycznych operacjach wymagających ścisłej poprawności rozważ inne mechanizmy.
Feature flags i konfiguracja – szybki odczyt flag przez wiele usług.
Geolokalizacja – komendy GEOADD i GEOSEARCH do wyszukiwania „najbliższych punktów”.
Wyszukiwanie wektorowe i AI – przechowywanie embeddingów, cache semantyczny dla odpowiedzi modeli językowych, pamięć agentów AI.

Kiedy Redis nie jest dobrym wyborem?

Redis nie zastąpi głównej bazy danych w większości systemów. Zwróć uwagę na ograniczenia:

Koszt pamięci – RAM kosztuje więcej niż dysk, więc trzymanie terabajtów danych bywa nieopłacalne.
Złożone zapytania i relacje – brak JOIN-ów i rozbudowanego SQL-a.
Trwałość – choćby z AOF ryzyko utraty ostatnich operacji jest większe niż w klasycznych bazach z pełnym wsparciem ACID.
Dane duże i rzadko używane – lepiej trzymać je w bazie dyskowej lub w storage obiektowym.

Dobra praktyka: Redis jako warstwa uzupełniająca, a źródło prawdy w PostgreSQL, MySQL lub MongoDB.

Redis vs Memcached – co wybrać?

Do niedawna Memcached był standardowym rozwiązaniem do cache, a Redis uchodził za jego bogatszego następcę. Oba narzędzia trzymają dane w RAM i oferują bardzo niskie opóźnienia, ale różnią się założeniami.

Cecha	Redis	Memcached
Typy danych	Stringi, listy, hashe, sety, sorted sets, streamy, JSON i inne	Tylko stringi (bajty)
Trwałość	RDB i AOF	Brak – dane tylko w pamięci
Replikacja i wysoka dostępność	Replikacja, Sentinel, Cluster	Brak wbudowanej replikacji; sharding po stronie klienta
Wielowątkowość	Wykonywanie komend jednowątkowe, wątki I/O od wersji 6.0	Natywnie wielowątkowy
Funkcje dodatkowe	Pub/Sub, Streamy, skrypty Lua i Functions, transakcje, ACL	Minimalistyczny zestaw
Zarządzanie pamięcią	Różne polityki eviction (LRU, LFU, TTL)	LRU w ramach slabów
Złożoność	Wyższa, więcej opcji do skonfigurowania	Bardzo prosty w obsłudze

Kiedy wybrać Redisa?

Wybierz Redisa, gdy potrzebujesz czegoś więcej niż prostego cache: kolejek, rankingów, sesji z trwałością, replikacji, atomowych operacji na strukturach danych czy Pub/Sub. Dziś to wybór domyślny w większości nowych projektów.

Kiedy wystarczy Memcached?

Memcached przez cały czas ma sens, gdy robisz czysty, prosty cache z dużymi, jednorodnymi obiektami i chcesz maksymalnie wykorzystać wiele rdzeni procesora przy minimum konfiguracji. Jest lekki, przewidywalny i sprawdzony. W wielu firmach działa od lat bez problemów.

W praktyce dyskusja „Redis vs Memcached” rzadko rozstrzyga się wydajnością. Większość aplikacji nie dotyka limitów żadnego z nich. Decyduje raczej zestaw funkcji i to, co zespół już zna.

Redis w produkcji: skalowanie i bezpieczeństwo

Wysoka dostępność i skalowanie

Pojedyncza instancja to pojedynczy punkt awarii. Redis oferuje kilka rozwiązań:

Replikacja master–replica – kopie danych do odczytu i na wypadek awarii.
Redis Sentinel – monitorowanie i automatyczny failover.
Redis Cluster – sharding danych na wiele węzłów (16 384 sloty hashujące), pozwalający skalować pamięć i przepustowość poziomo.

W chmurze możesz skorzystać z usług zarządzanych, takich jak Amazon ElastiCache i MemoryDB, Azure Cache for Redis (Microsoft wycofuje starszą ofertę na rzecz Azure Managed Redis), Google Memorystore czy Redis Cloud. Zdejmują one z Ciebie obowiązek utrzymania klastra.

Bezpieczeństwo

Redis domyślnie zakłada zaufane środowisko, więc wystawienie go publicznie bez zabezpieczeń to częsty powód incydentów. Pamiętaj, żeby:

nie wystawiać portu 6379 do internetu,
ustawić uwierzytelnianie i ACL (osobni użytkownicy z ograniczonymi uprawnieniami),
włączyć TLS dla połączeń między usługami,
wyłączyć lub zmienić nazwy niebezpiecznych komend (np. FLUSHALL, CONFIG),
regularnie aktualizować wersję.

Monitorowanie

Pilnuj kilku metryk: zużycia pamięci i fragmentacji, hit ratio cache (stosunek trafień do wszystkich odczytów), liczby połączeń, opóźnień oraz liczby wypchniętych kluczy (evicted_keys). Komenda INFO daje większość tych danych, a SLOWLOG pokazuje wolne operacje.

Licencje i Valkey – o czym musisz wiedzieć

W marcu 2024 roku Redis Ltd. zmienił licencję projektu z BSD na podwójną RSALv2 / SSPLv1, które nie są licencjami open source w rozumieniu OSI. Reakcja społeczności była szybka. Linux Foundation i firmy takie jak AWS, Google czy Oracle utworzyły fork o nazwie Valkey, rozwijany na licencji BSD i dziś dostępny m.in. w usługach zarządzanych AWS.

W 2025 roku, wraz z wydaniem Redis 8, firma dodała do licencji opcję AGPLv3, co ponownie przybliżyło projekt do świata open source. Dla zespołów korzystających z Redisa jako usługi we własnej aplikacji zmiany te zwykle nie mają praktycznych skutków. Ważne są jednak dla dostawców chmurowych i firm budujących produkty na bazie Redisa. jeżeli licencje mają dla Ciebie znaczenie, sprawdź dokładne warunki u źródła i przejrzyj aktualny stan obu projektów, bo sytuacja gwałtownie się zmienia.

Dobra wiadomość: Valkey pozostaje w dużej mierze zgodny z protokołem Redisa, więc większość klientów i narzędzi działa z obiema bazami.

Podsumowanie

Redis to jedno z tych narzędzi, które po poznaniu trudno wyrzucić z architektury. Jako cache przyspiesza aplikacje i odciąża bazę główną. Jako kolejka upraszcza przetwarzanie w tle. Jako serwer struktur danych rozwiązuje całą klasę problemów: od sesji i limitów żądań po rankingi i wyszukiwanie wektorowe.

Najważniejsze wnioski:

Redis to serwer struktur danych w pamięci, a nie tylko prosty cache.
W cache zawsze ustawiaj TTL i politykę eviction, a o inwalidacji pamiętaj od początku.
Do kolejek wybieraj Streamy lub gotowe biblioteki, a nie surowe Pub/Sub.
W porównaniu Redis vs Memcached Memcached wygrywa prostotą, a Redis funkcjonalnością i elastycznością.
Redis uzupełnia główną bazę danych, nie zastępuje jej.
Zabezpiecz instancję i obserwuj metryki, zanim ruch wzrośnie.