Pamięć podręczna (ang. cache) to mały, bardzo szybki bufor pamięci, który siedzi między procesorem a wolniejszą pamięcią operacyjną (RAM) i przechowuje kopie danych oraz instrukcji, po które sięgasz najczęściej. Idea jest prosta: zamiast za każdym razem biec po dane do odległej i powolnej RAM, procesor najpierw zagląda do podręcznego schowka tuż obok siebie. Jeśli znajdzie tam to, czego szuka, oszczędza mnóstwo cykli zegara.
Jak to działa
Cache działa na zasadzie lokalności: jeśli właśnie użyłeś jakiegoś adresu w pamięci, prawdopodobnie zaraz użyjesz go znowu albo sięgniesz po dane leżące obok. Procesor ładuje więc całe bloki danych z wyprzedzeniem. Gdy potrzebna wartość jest już w cache, mówimy o cache hit; gdy jej nie ma i trzeba jechać po nią dalej (do RAM albo na dysk), to cache miss i kara czasowa.
W procesorach cache jest wielopoziomowy. L1 to najmniejszy i najszybszy schowek, tuż przy rdzeniu (zwykle dziesiątki KB). L2 jest większy i nieco wolniejszy, a L3 bywa współdzielony przez wszystkie rdzenie i liczony w megabajtach. Im wyżej numer, tym więcej miejsca, ale tym dłużej trwa dostęp. Cała ta hierarchia istnieje, bo szybka pamięć jest droga, a duża pamięć jest wolna, więc trzeba kombinować pomiędzy.
Przykład z praktyki
Cache to nie tylko sprzęt. Tę samą koncepcję spotkasz wszędzie w stacku. Twój system trzyma page cache w RAM, żeby nie czytać tych samych plików z dysku w kółko. Na Linuksie możesz to podejrzeć komendą free -h w kolumnie buff/cache. W aplikacjach webowych klasykiem jest Redis albo Memcached trzymające wyniki zapytań do bazy. Sprawdzenie, czy klucz siedzi w Redisie, wygląda tak:
redis-cli GET user:42:profile
Jeśli zwróci wartość, masz hit i oszczędzasz zapytanie do bazy. Jeśli (nil) to miss i lecisz po dane do źródła.
Na co uważać
Największy ból z cache to invalidacja, czyli moment, w którym dane w schowku przestają być aktualne. Stąd słynny żart, że w informatyce są tylko dwa trudne problemy: invalidacja cache i nazywanie zmiennych. Klasyczny błąd juniora: zmieniasz coś w bazie, a strona dalej pokazuje stare dane, bo zapomniałeś wyczyścić cache. Drugi mit: „więcej cache = zawsze szybciej”. Niekoniecznie. Zbyt agresywne cache’owanie potrafi serwować nieświeże dane albo zjadać pamięć, której zabraknie czemuś ważniejszemu.
Pojęcia powiązane: cache hit i cache miss, TTL (czas życia wpisu), bufor, pamięć RAM, rejestry procesora, hierarchia pamięci, Redis, CDN.