Unieważnianie pamięci podręcznej w PHP nie polega na wybraniu TTL i przechowywaniu odpowiedzi w Redis. To decyzja dotycząca spójności: określenie, które informacje mogą być tymczasowo nieaktualne, jak długo oraz co powinno się wydarzyć, gdy zmieniają się dane źródłowe. Źle zaprojektowana pamięć podręczna może wyświetlić starą cenę, przyznać dostęp przy cofniętych uprawnieniach lub prezentować dostępność, która już nie istnieje. Zbyt zachowawcza pamięć podręczna z kolei przenosi całe obciążenie do bazy danych i traci swój cel.
Punktem wyjścia jest traktowanie każdego wpisu jako danych o określonym właścicielu, cyklu życia i ryzyku. Pozwala to produktowi, biznesowi i technologii uzgodnić, kiedy potencjalnie nieaktualny odczyt jest akceptowalny, a kiedy należy pobrać bieżący stan ze źródła prawdy.
Sklasyfikuj dane przed umieszczeniem ich w pamięci podręcznej
Nie wszystkie często odczytywane dane należy cache’ować ani nie wszystkie dopuszczają ten sam mechanizm. Oceń każdy odczyt według czterech kryteriów: zmienności, wpływu nieaktualności, kosztu zapytania źródła i tolerancji na awarię pamięci podręcznej.
- Niska zmienność i niski wpływ: publiczne katalogi, metadane lub niewrażliwe konfiguracje zwykle dopuszczają TTL wynoszący minuty lub godziny, zależnie od procesu ich zmiany.
- Średnia zmienność: karty produktów, agregaty paneli i wyniki wyszukiwania mogą być cache’owane, jeśli są unieważniane przy zmianie składających się na nie rekordów.
- Wysoki wpływ: uprawnienia, salda, limity, stany transakcyjne, stan magazynowy podczas potwierdzania zakupu i kontrole autoryzacji wymagają spójnego źródła prawdy albo jawnej strategii świeżości o bardzo rygorystycznych zasadach.
- Dane kosztowne w obliczeniu: raporty i pochodne podsumowania mogą uzasadniać użycie pamięci podręcznej, nawet jeśli nie są często odczytywane, lecz muszą deklarować, które encje je unieważniają.
Warto oddzielić pamięć podręczną prezentacji od pamięci podręcznej decyzji. Wyświetlanie przez kilka sekund poprzedniej nazwy kategorii może być akceptowalne. Używanie starej polityki do autoryzacji operacji zazwyczaj nie jest. W przypadku krytycznych decyzji odwołuj się do autorytatywnego źródła lub przechowuj wersje, które można zweryfikować przed podjęciem działania.
Zdefiniuj własność, klucze i kontrakty świeżości
Każdy wpis potrzebuje karty operacyjnej. Powinna wskazywać źródło prawdy, klucz, konsumentów, maksymalny TTL, zdarzenie unieważniające, zachowanie, gdy Redis nie jest dostępny, oraz właściciela funkcjonalnego lub technicznego. Bez tego kontraktu klucze się mnożą i nikt nie wie, co usunąć po zmianie.
Używaj przewidywalnych kluczy o wystarczającym zakresie. Na przykład product:42 reprezentuje konkretną encję; tenant:8:product:42 zapobiega mieszaniu danych między organizacjami; a dashboard:tenant:8:period:current identyfikuje wynik pochodny. Nie umieszczaj w kluczach tajnych danych ani nie używaj niestabilnych serializacji jako tożsamości.
Warto również zachować jednolity format wartości: payload, wersję lub datę wygenerowania oraz, gdy ma to znaczenie, wskaźnik świeżości. Konsument nie powinien zakładać, że odpowiedź z pamięci podręcznej jest równoważna odczytowi spójnemu transakcyjnie.
final class ProductCacheKey
{
public static function detail(int $tenantId, int $productId): string
{
return "tenant:{$tenantId}:product:{$productId}:v1";
}
}Sufiks schematu pozwala zmienić strukturę wartości bez konieczności lokalizowania i usuwania wszystkich historycznych wpisów. Nie zastępuje unieważniania danych biznesowych, ale zmniejsza ryzyko podczas ewolucji formatu.
Wybierz wzorzec aktualizacji zależnie od typu odczytu
Cache-aside dla odczytów nadających się do ponownego wykorzystania
W modelu cache-aside aplikacja najpierw szuka klucza; w przypadku braku wpisu w pamięci podręcznej odczytuje bazę danych, buduje wartość i zapisuje ją z TTL. Jest to proste i odpowiednie dla względnie stabilnych odczytów. Jego ograniczenie jest jasne: po zapisie ktoś musi usunąć lub zastąpić wpisy, których to dotyczy.
Unieważnienie musi nastąpić po zatwierdzeniu transakcji. Usunięcie przed commitem może sprawić, że inny proces odbuduje pamięć podręczną z nadal starą wartością. Jeśli aplikacja publikuje zdarzenia, wzorzec outbox pomaga zarejestrować zmianę w tej samej transakcji, a następnie niezawodnie dostarczyć polecenie unieważnienia.
Jawna aktualizacja i wersjonowanie
Jeśli encja jest bardzo często odczytywana, a jej zmiany są kontrolowane, wpis można zaktualizować po zatwierdzeniu zapisu. Pozwala to uniknąć kolejnego cache miss. Proces musi jednak generować dokładnie tę samą reprezentację, jakiej oczekują odczytujący; w przeciwnym razie unieważnienie i odbudowa są zwykle mniej ryzykowne.
Wersjonowanie kluczy jest przydatne w przypadku szerokich zależności. Zamiast usuwać wszystkie listy produktów organizacji, zwiększa się tenant:8:products:version, a listy zawierają tę liczbę w swoim kluczu. Stare listy wygasają samodzielnie. Takie podejście ogranicza masowe usuwanie, ale wymaga kontrolowania wzrostu liczby kluczy i nie powinno służyć do ukrywania źle zrozumianej zależności.
Kontroluj wyścigi i zależności pochodne
Typowy wyścig przebiega tak: odczyt nie trafia do pamięci podręcznej i pobiera starą wartość; zapis zostaje zatwierdzony i unieważnia wpis; pierwszy odczyt kończy się i ponownie zapisuje starą wartość. W przypadku wrażliwych danych połącz unieważnianie z wersją encji lub krótką blokadą odbudowy. Przed zapisaniem wyliczonej wartości sprawdź, czy odczytana wersja nadal jest aktualna. Jeśli nie, odrzuć wynik i odczytaj ponownie.
Blokady rozproszone powinny być krótkie, mieć wygaśnięcie i nie mogą stać się pojedynczym punktem blokowania. Ich funkcją jest ograniczanie równoczesnych odbudów, a nie samodzielne zapewnienie spójności biznesowej. Jeśli blokada nie zostanie uzyskana, jedną z opcji jest krótkie oczekiwanie na odbudowaną wartość lub zezwolenie na ograniczony bezpośredni odczyt.
Unieważnianie według zależności wymaga inwentaryzacji. Zmiana produktu może wpływać na jego szczegóły, kilka list, wyniki wyszukiwania, liczniki i panel. Zmiana roli może wpływać na efektywne uprawnienia użytkowników i pochodne menu. Modeluj te relacje jawnie:
- Unieważniaj bezpośrednią encję za pomocą jej klucza.
- Unieważniaj lub wersjonuj kolekcje i agregaty, które od niej zależą.
- Przeliczaj asynchronicznie kosztowne wyniki, jeśli pozwala na to doświadczenie użytkownika.
- Nie myl czyszczenia widoku z aktualizowaniem źródła prawdy.
Gdy relacja nie jest łatwa do wyliczenia, przestrzeń wersji według organizacji, katalogu lub polityki jest zwykle bezpieczniejsza niż próba odkrycia wszystkich dotkniętych kluczy za pomocą wzorców globalnego usuwania.
Używaj TTL, jittera i limitów, aby chronić źródło
TTL jest siatką bezpieczeństwa, a nie jedynym mechanizmem spójności. Nawet prawidłowo unieważniony klucz powinien wygasać: mogą wystąpić błędy dostarczania zdarzeń, błędy wdrożenia lub osierocone wpisy. Dobieraj TTL zgodnie z kosztem błędu, a nie wyłącznie kosztem zapytania.
Stosuj losowy jitter do TTL, aby tysiące kluczy utworzonych w tym samym czasie nie wygasały jednocześnie. Ponadto chroń źródło przed lawiną cache missów za pomocą blokady odbudowy na klucz, limitów współbieżności i limitów dla każdego konsumenta. W przypadku danych niekrytycznych można podać lekko przeterminowaną wartość, gdy jeden proces ją przelicza; w przypadku uprawnień lub dostępności wykorzystywanej do podejmowania decyzji tę technikę należy odrzucić albo ograniczyć do scenariuszy wyraźnie zatwierdzonych.
Zaprojektuj degradację na wypadek awarii Redis
Redis jest zależnością operacyjną, a nie źródłem prawdy. Jeśli nie odpowiada, aplikacja potrzebuje zdefiniowanego trybu degradacji. W przypadku mało kosztownego publicznego odczytu może bezpośrednio odpytwać bazę danych z limitami czasu. Dla kosztownych zapytań warto zastosować ograniczanie obciążenia, zmniejszyć liczbę pól, odpowiedzieć statusem tymczasowej niedostępności lub użyć odpowiedniej repliki, jeśli architektura ją przewiduje.
Nie zamieniaj awarii pamięci podręcznej w wyczerpanie połączeń z bazą danych. Zdefiniuj krótkie timeouty, circuit breakers, budżety zapytań i metryki według ścieżki. W przypadku krytycznych danych lepiej odrzucić operację niż podjąć decyzję na podstawie uprawnień, sald lub stanu magazynowego, których świeżości nie można zagwarantować.
Testuj i obserwuj świeżość, nie tylko trafienia
Wysoki współczynnik trafień nie dowodzi, że pamięć podręczna jest poprawna. Instrumentuj trafienia, cache missy, opóźnienia, błędy odczytu i zapisu, pozostały TTL, blokady odbudowy, wysłane i nieudane unieważnienia, a także zapytania i nasycenie bazy danych. Powiąż te sygnały z każdą rodziną kluczy, a nie tylko z Redis jako usługą globalną.
W testach uwzględnij co najmniej początkowy odczyt, późniejszą aktualizację, usunięcie, unieważnienie po commicie, awarię pamięci podręcznej oraz wyścigi między czytającym a zapisującym. Zweryfikuj, że użytkownik traci dostęp po cofnięciu uprawnienia, że lista odzwierciedla modyfikację zgodnie ze swoim kontraktem świeżości oraz że nieudane unieważnienie aktywuje alerty lub odzyskiwanie.
Lista kontrolna dla istniejącej aplikacji PHP
- Wymień powtarzane odczyty i sklasyfikuj je według ryzyka, zmienności i kosztu.
- Określ źródło prawdy i maksymalną tolerancję nieaktualności dla każdego rodzaju danych.
- Udokumentuj klucze, TTL, zależności, konsumentów i zdarzenie unieważniające.
- Wykonuj unieważnienia lub aktualizacje wyłącznie po potwierdzonym commicie.
- Chroń przed równoczesnymi odbudowami i dodaj jitter do istotnych wygaśnięć.
- Zdefiniuj tryb degradacji na wypadek niedostępności Redis bez przeciążania bazy danych.
- Mierz świeżość i unieważnienia, a nie tylko współczynnik trafień.
- Okresowo przeglądaj klucze bez właściciela, nadmierne TTL i nieobjęte zależności.
Niezawodna strategia unieważniania pamięci podręcznej w PHP uwidacznia swoje kompromisy: co może stać się nieaktualne, na jaki okres, jak jest korygowane i co dzieje się, gdy komponent ulegnie awarii. Ta przejrzystość jest cenniejsza niż bezkrytyczne dodawanie pamięci podręcznej.
