Redis w pigułce: czym jest i kiedy go używać

Redis tak często bywa opisywany jako „tylko cache”, że ludzie go nie doceniają. A szkoda, bo to naprawdę wszechstronne narzędzie, a zrozumienie, co faktycznie robi pod maską, od razu wyjaśnia, dlaczego pojawia się w tak wielu systemach produkcyjnych.

Czym właściwie jest Redis

Redis to magazyn danych w pamięci (in-memory) – trzyma dane w RAM-ie zamiast na dysku i właśnie dlatego przy obsługiwanych przez siebie operacjach jest nieporównanie szybszy od tradycyjnej bazy danych. Odczyt z pamięci zajmuje mikrosekundy, a odczyt z dysku, nawet szybkiego SSD, trwa wyraźnie dłużej. Ta różnica szybkości to cały powód istnienia Redisa.

W przeciwieństwie do zwykłego cache’u typu klucz-wartość Redis bezpośrednio obsługuje naprawdę przydatne struktury danych – ciągi znaków, listy, zbiory, zbiory posortowane, hashe – więc nie jesteście ograniczeni do zapisywania i odczytywania prostych blobów. Można dodawać elementy do listy i z niej zdejmować, atomowo zwiększać licznik albo odpytywać posortowany zbiór według wyniku – wszystko jako natywne, szybkie operacje.

Do czego faktycznie używa się Redisa

Cache: najczęstsze zastosowanie – wynik kosztownego zapytania do bazy danych lub wywołania API zapisuje się w Redisie i przy kolejnych żądaniach serwuje z pamięci, zamiast za każdym razem liczyć go od nowa.
Przechowywanie sesji: dane sesji użytkowników są nieustannie odczytywane i zapisywane, a nie wymagają gwarancji długotrwałej trwałości, więc naturalnie pasują do czegoś tak szybkiego.
Limitowanie liczby żądań (rate limiting): atomowe operacje na licznikach w Redisie sprawiają, że sprawdzenie „czy ten adres IP wysłał w ostatniej minucie zbyt wiele żądań” jest szybkie i niezawodne.
Rankingi w czasie rzeczywistym: zbiory posortowane są stworzone niemal dokładnie do zapytań w stylu „top 10 według wyniku”, aktualizowanych na bieżąco.
Komunikacja pub/sub: Redis potrafi w czasie rzeczywistym rozgłaszać wiadomości między różnymi częściami systemu, co przydaje się np. przy powiadomieniach na żywo.
Kolejki zadań: wiele systemów zadań w tle wykorzystuje Redisa jako magazyn zadań oczekujących na przetworzenie.

Kompromis, który trzeba rozumieć

Szybkość Redisa wynika z tego, że działa w pamięci, a pamięć jest domyślnie zarówno droższa, jak i mniej trwała niż dysk. Jeśli serwer Redisa się zrestartuje, dane mogą przepaść, chyba że wprost skonfigurowaliście ich utrwalanie (Redis to obsługuje, choć z własnymi kompromisami). Praktyczny wniosek: Redis świetnie sprawdza się przy danych, które są jednorazowe albo dają się odtworzyć – cache zawsze można odbudować ze źródłowej bazy danych – i wymaga starannej konfiguracji, jeśli przechowujecie w nim coś, czego naprawdę nie możecie stracić.

Kiedy naprawdę warto po niego sięgnąć

Jeśli macie zapytanie lub obliczenie, które jest kosztowne i nie musi być przeliczane przy każdym żądaniu – zapiszcie je w cache’u Redisa. Jeśli budujecie cokolwiek, co wymaga limitów żądań, liczników w czasie rzeczywistym albo rankingów, Redis poradzi sobie z tym lepiej niż jakakolwiek uniwersalna relacyjna baza danych. Jeśli natomiast dane bezwzględnie muszą przetrwać restart serwera i nie da się ich odtworzyć z innego źródła, lepiej sprawdzi się baza projektowana z trwałością jako głównym celem, taka jak Postgres.

Ustalenie, które części systemu powinny trafić do szybkiego, ulotnego magazynu w rodzaju Redisa, a które do trwałej bazy danych, to decyzja, którą podejmujemy niemal w każdym projekcie infrastruktury chmurowej. Często to właśnie ona decyduje o tym, czy produkt pozostaje szybki pod realnym obciążeniem, czy po cichu zwalnia w miarę wzrostu.