Technologie und Infrastruktur → Cache-Ebenen und Datenspeicherung

Cache-Ebenen und Datenspeicherung

1) Warum Sie einen mehrschichtigen Cache benötigen

Cache ist ein kurzer Weg zur Antwort, ohne in „teure“ Subsysteme (DBs, externe APIs, Netzwerke) zu gehen. Multilayer verteilt die Last: Browser → CDN/Edge → Anwendungsschicht → verteilter Cache → DB/Speicher. Ziele: Reduzieren Sie die P95/P99, entladen Sie den Ursprung, halten Sie Spitzen besser stand und reduzieren Sie die Kosten für Bytes.

2) Karte der Cache-Ebenen

1. Браузер: `Cache-Control`, `ETag`, `Last-Modified`, `stale-while-revalidate`.
2. CDN/Edge: TTL/ключ, Vary, Signed URLs, image-resize; tiered/shield.
3. API Gateway/Service Mesh: Kurz lebender Antwortcache über sicheres GET.
4. Anwendung (in-process): LRU/LFU, Near-Cache für „heiße“ Schlüssel, Millisekunden.
5. Verteilter Cache (Redis/Memcached) - Die Basisebene für die Dynamik.
6. DB-Caches: Pg/Innodb-Puffer, PgBouncer-Multiplexing, materialisierte Ansichten.
7. Disk/Object Stops: vorkompilierte Snapshots, Blob-Cache (z.B. S3 + CDN).

Das Prinzip: "je näher am Benutzer - desto kürzer die TTL und weniger Personalisierung; Je näher an den Daten, desto reicher die Konsistenzpolitik".

3) Caching-Muster

Cache-Aside (Lazy): Wir lesen → bei MISS laden wir von der Quelle → legen sie in den Cache. Einfach, gibt TTL-Steuerung.
Read-Through: Die App liest durch einen Cache, den sie selbst aus der Quelle zieht. Es ist bequem, die Politik zu zentralisieren.
Write-Through: Die Aufnahme geht sofort in den Cache und in die Quelle. Konsistenter, aber teurer in der Aufnahme.
Write-Back (Write-Behind): Wir schreiben in den Cache, die Quelle wird asynchron aktualisiert (Warteschlange). Hohe Geschwindigkeit, Liefergarantien und Idempotenz erforderlich.
Refresh-Ahead: Bei „Top“ -Schlüsseln aktualisieren wir den Wert, bevor die TTL abläuft.

Wo was: Spielkarten/Kataloge - cache-aside/read-through; Zähler/Führungstafeln - write-back + CRDT/Aggregationen; Währungs-/Limitverzeichnisse - read-through mit kontrollierter TTL.

4) Schlüssel, Segmentierung und Namensgebung

Шаблон: `domain:entity:{id}:v{schema}|region={R}|currency={C}|lang={L}`.
Fügen Sie nur das in den Schlüssel ein, was die Antwort tatsächlich ändert (Region, Währung, Sprache, Version des Schemas).
Versionierung von Schemata: Bei inkompatiblen Änderungen erhöhen Sie „vN“ im Schlüssel und vermeiden Sie Masseneinschläge.
Namespacing nach Produkten/Tenanten: 'tenant: {t}:...' - kritisch für multi-tenant.
Ein Bloom-Filter auf die „Existenz des Schlüssels“ kann das Wandern in die Quelle reduzieren.

5) TTL, Frische und Behinderung

• Statik (gehashte Dateien): 30-365 Tage + 'immutable';
• Kataloge/Banner: 5-60 Minuten + 'stale-while-revalidate';
• Leaderboards/Zitate: 2-15 Sekunden;
• Verzeichnisse (Währungen/Limits): 1-10 Minuten.
• Behinderung durch Ereignisse: wir veröffentlichen 'Produkt. updated '→ Behinderung des Punktschlüssels/Präfix.
• Tag-based purge: Gruppenbereinigungen nach Tag (Promo/Katalogfreigabe).
• Soft-Expiry: Nach Ablauf der TTL geben wir die veraltete als' stale' ab, parallel aktualisieren wir (SWR/SIE).
• Versioned Keys> Bulk Purge: billiger und sicherer.

6) Stampede, „heiße“ Schlüssel und Wettbewerb

• Einzelflug (Coalescing-Anfrage): Ein Anführer aktualisiert den Schlüssel, der Rest wartet.
• TTL-Jitter: Erodieren Sie die Lecks, indem Sie einen einmaligen Zusammenbruch vermeiden.
• SWR lokal: Wir geben dem Nutzer den überfälligen Wert, im Hintergrund aktualisieren wir.

• Replizieren des „heißen“ Schlüssels in mehrere Schlitze' Schlüssel # 1.. N', verteilt durch Lesen;
• near-cache im Prozessspeicher;
• prewarm/refresh-ahead vor den Gipfeln (Turniere/Matches).
• Concarrency-Update-Limits für schwere Schlüssel.

7) Konsistenz und Kreuzschichten

Write-invalidate: beim Schreiben in die Quelle - synchron die entsprechenden Schlüssel (pub/sub) deaktivieren.
Read-repair: Bei Unstimmigkeiten den Cache mit dem korrekten Wert aktualisieren.
Eventual vs Strong: Kritische Geldtransaktionen können direkt/mit kurzer TTL gelesen werden; UI-Vitrinen und Statistiken sind evental.
CRDT/Aggregatoren: für verteilte Zähler/Ratings - „merge-safe“ -Strukturen (G-Counter, Top-K auf Threads).
Kaskadierende Behinderung: Das „Spiel“ -Update behindert die Karte + Liste + benutzerdefinierten Empfehlungscache.

8) Serialisierung, Komprimierung und Format

Formate: Protobuf/MessagePack schneller als JSON; für CDN/Browser - JSON mit Brotli.
Kompression in Redis: vorteilhaft für Objekte> 1-2 KB, aber achten Sie auf die CPU.
Partielle Antworten/Felder auf Anforderung: weniger Bytes → weniger TTFB und RAM.

9) Verdrängungspolitik und Größe

LRU (Standard) - sicher; LFU ist besser für „populäre“ Inhalte.
Größe der Schlüssel/Werte: Behalten Sie die Kontrolle (Metriken 'avg value size', 'max').
Quoten nach Namespace/Tenant, damit ein Produkt nicht den gesamten Cache „frisst“.

10) Sicherheit und PII/PCI

Persönliche/finanzielle Daten - nicht auf CDN/Edge und in allgemeinen Schichten zwischenspeichern; Verwenden Sie Token/Projektionen.
Verschlüsselung sensibler Werte in Redis über Client-Side Crypto (mit Vorsicht vor TTL-Kontrollverlusten).
Strenge ACL und Isolierung von Netzwerken; feste NAT/IP für egress zu den Anbietern.

11) Beobachtbarkeit und Cache-SLO

• Hit Ratio (nach Ebenen und Präfixen), Origin Offload.
• TTFB/P95/P99 vor/nach dem Cache, Latency Redis.
• Evictions, OOM, keyspace hits/misses.
• Stampede Rate (Anteil der parallelen Updates), refresh time.
• Stale served % и Freshness lag.

• Spielekatalog: Hit Ratio ≥ 85%, TTFB P95 ≤ 150 ms (Rand).
• API-Handbücher: Revalidation-Hit ≥ 60%, P95 ≤ 200 ms.
• Redis: P99 Operation ≤ 5 ms, evictions nicht mehr als 1% pro Stunde.

12) FinOps: Cache-Kosten

$/GB-Monat RAM vs $/RPS Herkunft: Berechnen Sie den Amortisationspunkt.
Offload und egress: CDN + Redis reduzieren den ausgehenden Datenverkehr von Regional-Origin.
Image/WebP/AVIF und Denormalisierung bieten die größten Byte-Einsparungen.
Begrenzen Sie „liebe MISS“: analytica „bytes × MISS × region“.

13) Beispiele (Fragmente)

13. 1 Cache-Aside mit Einzelflug (Pseudocode)

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 Veröffentlichung der Behinderung nach Veranstaltung

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

Der Consumer abonniert den Kanal und macht 'DEL '/' PUBLISH' zu den entsprechenden Schlüsseln/Tags.

13. 3 Schlüssel mit Schemaversion und Locale

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

14) Checkliste Umsetzung

1. Cache Level Map und TTL-Matrix (statisch/halbstatisch/API).
2. Schlüsselbezeichnung: Domäne, Schema-Version, Ort/Region/Währung, Tenant.
3. Auswahl des Per-Endpoint-Musters (aside/read-through/write-through/back).
4. SWR/SIE, Einzelflug und TTL-Jitter gegen Stampede.
5. Behinderung durch Veranstaltungen (pub/sub), Tag-Purge für Gruppen.
6. Near-Cache für Hot Keys und Prewarm vor Peaks.
7. Formate und Kompression (protobuf/MsgPack, Brotli), Größenkontrolle.
8. LRU/LFU-Richtlinien, Quoten für Namespace/Tenant.
9. SLO/метрики: hit ratio, latency, evictions, stale %, freshness lag.
10. Sicherheit: No-Store für Personal, Tokenisierung, Netzwerk/ACL.

15) Anti-Muster

„no-cache“ „nur für den Fall“ und TTL-Ausfälle - Null Offload.
Der Schlüssel enthält alle Abfragen/Überschriften → eine Explosion der Kardinalität.
Massive Verfolgung von „nur CDN/Redis“ bei jeder Veröffentlichung.
Fehlender Schutz vor Stampede und einmaliges Auslaufen der „Top Keys“.
Ein einziges gemeinsames Redis ohne Quoten/Isolierung; Der „heiße“ Tenant frisst den ganzen Cache.
Caching von persönlichen Antworten auf Edge/CDN.
Keine Telemetrie freshness/evictions → blinde Kontrolle.

16) iGaming/Fintech Kontext: Praktische Hinweise

Leaderboards/Ratings: TTL 2-10 s, Aggregate-Streams + CRDT, SWR bei Störungen.
Spiele-Verzeichnis/Banner: CDN + Redis; Schlüssel: Region/Währung/Sprache; Behinderung durch „promo: update“ -Tags.
Zahlungsstatus: kein Cache auf dem Schreibpfad; Lesen - eine kurze TTL (≤3 -5 s) oder eine direkte Anfrage.
KYC/AML antwortet: Cache nicht-PII-Derivate (Status), nicht speichern Bilder/Dokumente in Redis.
VIP-Pfad: separater Namespace/Redis-Pool, bevorzugter Service.

Summe

Eine starke Cache-Strategie ist die Architektur der Ebenen, die richtigen Aktualisierungsmuster, eine durchdachte TTL/Behinderung, Stampede-Resistenz, saubere Schlüssel und Versionen sowie Beobachtbarkeit und FinOps. Indem Sie diesen Prinzipien folgen, stabilisieren Sie die Schwänze der P95/P99, reduzieren die Belastung der Quellen und erhalten vorhersehbare Kosten für eine Millisekunde - genau dort, wo es für das Produkt und das Unternehmen am wichtigsten ist.