Technologia i infrastruktura → Poziomy pamięci podręcznej i przechowywanie danych

Poziomy pamięci podręcznej i przechowywanie danych

1) Dlaczego potrzebujesz wielowarstwowej pamięci podręcznej

Pamięć podręczna jest krótką ścieżką do odpowiedzi bez przechodzenia do „drogich” podsystemów (bazy danych, zewnętrzne interfejsy API, sieci). Warstwowanie rozprowadza obciążenie: przeglądarka → CDN/krawędź → warstwa aplikacji → rozproszona pamięć podręczna → baza danych/przechowywanie. Cele: zmniejszenie P95/P99, rozładunek pochodzenia, wytrzymać piki mocniej i zmniejszyć koszty bajtów.

2) Mapa poziomu pamięci podręcznej

1. Брабей: 'Cache-Control', 'ETag', 'Last-Modified', 'stale-while-revalidate'.
2. CDN/Edge: TTL/klel, Vary, Podpisane adresy URL, rozmiar obrazu; wielopoziomowy/tarcza.
3. API Gateway/Service Mesh: krótkotrwała pamięć podręczna odpowiedzi dla bezpiecznego GET.
4. Zastosowanie (w procesie): LRU/LFU, near-cache dla kluczy gorących, milisekund.
5. Pamięć podręczna rozproszona (Redis/Memcached): główna warstwa dla dynamiki.
6. Bufory DB: bufory Pg/Innodb, multipleksowanie PgBouncer, zmaterializowane widoki.
7. Sklepy dyskowe/obiektowe: wstępnie skomputeryzowane migawki, pamięć podręczna blob (na przykład S3 + CDN).

Zasada: "im bliżej użytkownika, tym krótszy TTL i mniej personalizacji; im bliżej danych, tym bogatsza jest polityka spójności"

3) Wzory pamięci podręcznej

Cache-Aside (Lazy): czytamy → z MISS ładujemy z źródła → umieścić go w pamięci podręcznej. Proste, daje kontrolę TTL.
Read-Through: aplikacja czyta się za pomocą pamięci podręcznej, która ciągnie się z samego źródła. Wygodnie jest scentralizować politykę.
Writing-Through: nagranie trafia do pamięci podręcznej i do źródła natychmiast. Bardziej konsekwentne, ale droższe.
Write-Back (Write-Behind): piszemy do pamięci podręcznej, źródło jest aktualizowane asynchronicznie (kolejka). Wysoka prędkość, gwarancje wysyłki i wymagana iempotencja.
Refresh-Ahead: dla „top” klawiszy, zaktualizować wartość przed wygaśnięciem TTL.

Gdzie co: karty/katalogi gier - cache-aside/read-through; liczniki/tablice liderów - odpisy zwrotne + CRDT/agregacja; katalogi waluty/limitów - odczytywanie z kontrolowanym TTL.

4) Klucze, segmentacja i nazewnictwo

Маблой: 'domena: podmiot: {id}: v{schema}|region={R}|currency={C}|lang={L}'.
Wpisz w kluczu tylko to, co faktycznie zmienia odpowiedź (region, waluta, język, wersja schematu).
Wersioning schematu: dla niezgodnych zmian - podnieść 'vN' w kluczu, unikając masowego oczyszczenia.
Nazwa produktu/najemcy: „najemca: {t}:...” - krytyczne dla wielu najemców.
Filtr Bloom dla „istnienia klucza” może zmniejszyć podróże do źródła.

5) TTL, świeżość i niepełnosprawność

• pliki statyczne (skodyfikowane): 30-365 dni + „niezmienne”;
• katalogi/banery: 5-60 minut + „stale-while-revalidate”;
• lider/cytaty: 2-15 sekund;
• katalogi (waluty/limity): 1-10 minut.
• Zdarzenia związane z niepełnosprawnością: opublikować "produkt. zaktualizowany '→ klucz kropki/niepełnosprawność prefiksu.
• Tag-based purge: group purges by tag (promo/catalog release).
• Soft-Expiry: po wygaśnięciu TTL podajemy przestarzałą jako „stale”, aktualizujemy ją równolegle (SWR/SIE).
• Wersjonowane klucze> masowe oczyszczanie: tańsze i bezpieczniejsze.

6) Stampede, gorące klucze i konkurencja

• Pojedynczy lot (koalescencja żądania): jeden lider aktualizuje klucz, reszta czeka.
• TTL jitter: rozmyć odpływ, unikając jednorazowego upadku.
• SWR lokalnie: podajemy wygasłą wartość użytkownikowi, aktualizujemy ją w tle.

• Hot key replikacja do wielu 'klucz # 1.. N 'sloty rozłożone przez czytanie
• pamięci podręcznej w pamięci procesowej;
• prewarm/refresh-ahead przed wybraniami (turnieje/mecze).
• Limity aktualizacji konkarrencji dla kluczy ciężkich.

7) Spójność i warstwy poprzeczne

Zapisz-unieważnić: podczas pisania do źródła - synchronicznie wyłączyć odpowiednie klucze (pub/sub).
Odczyt-naprawa: w przypadku rozbieżności zaktualizuj pamięć podręczną o właściwej wartości.
Eventual vs Strong: krytyczne transakcje gotówkowe są odczytywane bezpośrednio/z krótkim TTL; Prezentacje i statystyki UI - eventual.
CRDT/agregatory: dla rozproszonych liczników/ratingów - struktury „bezpieczne łączenie” (G-Counter, Top-K na strumieniach).
Niepełnosprawność kaskadowa: Aktualizacja „gry” wyłącza kartę + listę + niestandardową pamięć podręczną rekomendacji.

8) Serializacja, kompresja i format

Formaty: protobuff/ Pack szybciej niż JSON; dla CDN/przeglądarki - JSON z Brotli.
Kompresja w Redis: korzystne dla obiektów> 1-2 KB, ale mieć oko na procesor.
Częściowe odpowiedzi/pola na żądanie: mniej bajtów → mniej TTFB i RAM.

9) Zasady i rozmiar preempcji

LRU (domyślnie) - bezpieczne; LFU jest lepsze dla „popularnych” treści.
Rozmiar klucza/wartości: pozostać pod kontrolą (mierniki „rozmiar wartości avg”, „max”).
Powierzchnia nazw/kwoty najemcy, tak aby jeden produkt nie „zjadł” całego pamięci podręcznej.

10) Bezpieczeństwo i PII/PCI

Dane osobowe/finansowe - nie przechowywać na CDN/krawędzi i we wspólnych warstwach; używać żetonów/projekcji.
Szyfrowanie wartości wrażliwych w programie Redis za pomocą kryptofilu klienckiego (z ostrożnością o stratach kontrolnych TTL).
ścisłe ACL i izolacja sieci; stałe NAT/IP dla dostawców.

11) Obserwowalność i pamięć podręczna SLO

• Hit Ratio (według warstwy i prefiksu), Origin Offload.
• TTFB/P95/P99 przed/po pamięci podręcznej, Latency Redis.
• Eksmisje, OOM, keyspace trafienia/brakuje.
• Szybkość stampede, czas odświeżenia.
• Stale serwowane% do świeżości lag.

• Katalog gier: Współczynnik trafienia ≥ 85%, TTFB P95 ≤ 150 ms (krawędź).
• Katalogi API: Przedłużenie ważności ≥ 60%, P95 ≤ 200 ms.
• Redis: operacja P99 ≤ 5 ms, eksmisje nie więcej niż 1% na godzinę.

12) FinOps: wartość pamięci podręcznej

$/GB miesiąc RAM vs $/RPS pochodzenie: obliczyć punkt zwrotu.
Offload and egress: CDN + Redis zmniejsza ruch wychodzący z regionu.
Obrazek/WebP/AVIF i denormalizacja zapewniają największe oszczędności bajtów.
Limit "drogie MISS': analityka" bajty × MISS × region ".

13) Przykłady (fragmenty)

13. 1 Cache-Off z pojedynczym lotem (pseudokoda)

python def get(key, ttl, loader):
val = redis. get(key)
if val: return val with single_flight (key): # only one updates val = redis. get (key) # double check if val: return val data = loader () # request to source redis. setex(key, ttl_with_jitter(ttl), serialize(data))
return data

13. 2 Publikacja niepełnosprawności według zdarzeń

json
{
"event": "game. updated",
"game_id": "g123",
"affected": ["catalog:list:region=TR", "game:card:g123:"]
}

Konsument zapisuje się do kanału i sprawia, że 'DEL'/' PUBLISH' match klucze/tagi.

13. 3 Klucz z wersją schematu i locale

game:card:v2:id=g123    region=BR    currency=BRL    lang=pt-BR

14) Lista kontrolna wdrażania

1. Mapa poziomu pamięci podręcznej i matryca TTL (statyczna/półstacjonarna/API).
2. Nazwa klucza: domena, wersja schematu, lokalna/regionalna/waluta, najemca.
3. Wybierz wzór per-endpoint (ask/read-through/write-through/back).
4. SWR/SIE, pojedynczy lot i TTL jitter kontra stampede.
5. Wyłączone przez zdarzenia (pub/sub), tag-purge dla grup.
6. Bliski pamięci podręcznej na gorące klucze i przedpokój przed szczytami.
7. Formaty i kompresja (protobuf/MsgPack, Brotli), kontrola wielkości.
8. Polityka LRU/LFU, obszar nazw/kwoty najemcy.
9. SLO/метрика: współczynnik trafień, opóźnienie, eksmisje, stale%, świeżość opóźnienia.
10. Bezpieczeństwo: brak sklepu osobistego, tokenizacja, sieć/ACL.

15) Anty-wzory

'no-cache' „just in case” i awarie TTL są zero offload.
Klucz obejmuje wszystkie zapytania/nagłówki → eksplozja kardynalności.
Masowe oczyszczanie „całkowite CDN/Redis” z każdym wydaniem.
Brak ochrony przed stampede i jednorazowe wygaśnięcie „top keys”.
Pojedynczy wspólny program Redis bez kwot/izolacji; „Gorący” lokator zjada cały bufor.
Buforowanie osobistych odpowiedzi na krawędź/CDN.
Brak świeżości/eksmisji telemetrii → ślepa kontrola.

16) Kontekst iGaming/fintech: uwagi praktyczne

Lidery/oceny: TTL 2-10 s, strumienie kruszywa + CRDT, SWR w awariach.
Katalog gier/banery: CDN + Redis; klucz: region/waluta/język; niepełnosprawność przez „promo: update” tagi.
Statusy płatności: brak pamięci podręcznej w ścieżce zapisu; read - krótki TTL (≤ 3 -5 sekund) lub bezpośrednie żądanie.
Odpowiedzi KYC/AML: cache pochodne inne niż PII (statusy), nie przechowuj obrazów/dokumentów w Redis.
Ścieżka VIP: oddzielny obszar nazw/pula Redis, usługa priorytetowa.

Razem

Silna strategia pamięci podręcznej to architektura poziomu, prawidłowe wzorce aktualizacji, przemyślana TTL/niepełnosprawność, odporność na stampede, schludne klucze i wersje oraz obserwowalność i FinOp. Przestrzegając tych zasad, można ustabilizować ogony P95/P99, zmniejszyć obciążenie źródeł i uzyskać przewidywalny koszt na milisekundę - dokładnie tam, gdzie jest to najważniejsze dla produktu i biznesu.