CDN-Caching und TTL-Optimierung

Cache-Control: public, max-age=31536000, immutable

Cache-Control: public, s-maxage=300, max-age=60, stale-while-revalidate=600, stale-if-error=86400
ETag: "a1c3..."

Cache-Schlüssel: Design und Normalisierung

Ziel ist es, dass die im Wesentlichen gleichen Anfragen im selben Objekt landen.

URL-Normalisierung: Register, Double Slash, Trailing-Slash, Reihenfolge der Query-Parameter.
Ignoriere „Rauschen“: 'utm _', 'fbclid',' gclid', beliebige Reftags.
Limitiertes Vary: nur wirklich aussagekräftige Überschriften ('Accept-Encoding', manchmal 'Accept', 'Accept-Language' für locale).
Geräteklasse: Verwenden Sie bei Bedarf 2-3 Klassen (Mobile/Desktop/Tablet) und nicht den endlosen User-Agent des Zweigs.
Auth-Kontext: Standardmäßig nicht privat zwischenspeichern; Verwenden Sie signierte URLs/Cookies-Bypass oder trennen Sie öffentliche/private Pfade.

Surrogate-Key: product:123 catalog
Cache-Control: public, s-maxage=300, stale-while-revalidate=600
Vary: Accept-Encoding

TTL-Strategien nach Inhaltstyp

Behindertenrichtlinien

Von URL/Prefix: „Fegen Sie alles unter '/static/2025-11-05/'“.
Durch Tag/Schlüssel: „entfernen Sie alle' Katalog 'und' Produkt: 123'“.
Soft Purge: als veraltet markieren, kein Objekt löschen - schnelleres Nachfüllen.
Event-driven: Ein CI/CD- oder Admin-Event ruft den Webhook „invalidate tags“ auf.

Empfehlung: Kombinieren Sie beide Taktiken: Versionierung von Pfaden für Assets + Tag-Purge für Inhalte/Seiten.

Tiered-cache, origin-shield и prewarm

Tiered-Cache: Regionale CDN-Ebenen → weniger Anfragen nach Herkunft.
Ursprung-Schild: ein „Schild“ POP zu Ursprung - verbessert die Lokalität und Hit-Verhältnis.
Prewarm (pre-fetch): Aufwärmen der heißen URLs/Caches vor dem Event/Release.
Negativer Cache: Caching 5xx/Timeout kurz (30-120 s), um den Ursprung nicht mit einem Sturm von Retrays zu überwältigen.

API-Cache: Wann Sie können

Nur GET/HEAD und idempotent.
Schlüssel: Pfad + wesentliche Abfragen (z.B.'? category =... & page =...').
Validierung: 'ETag '/' Last-Modified' und kurz' s-maxage'.
Filter nach Benutzer: Bringen Sie die Personalisierung auf die Client/Edge-Funktion oder verwenden Sie signed-requests + „öffentliche“ Antwort.

Cache-Control: public, s-maxage=30, max-age=5, stale-while-revalidate=120, stale-if-error=600
ETag: "feed-v42"

Schutz vor Cache-Vergiftung (Cache-Poisoning)

Starre Normalisierung von URLs/Titeln; die weiße Liste der Parameter im Schlüssel.
Zuschneiden verdächtiger Header/Duplikate ('X-Forwarded-', erweitert 'Accept').
Beschränkung 'Vary' und Kontrolle der Größe/Anzahl der Überschriften.
Domain Split: Privat/Admin - auf einem separaten Namen ohne Cache.
Validierung der Antworten: Zwischenspeichern Sie 4xx nicht (außer 404 für Statik), zwischenspeichern Sie keine „benutzerdefinierten“ Seiten ohne explizite Richtlinie.

Komprimierung und Formate

Brotli für Text (js/css/json), gzip - fallback; Vorkomprimierte Assets sind zulässig.
Bilder: webp/avif wo Unterstützung; Verwenden Sie' Vary: Accept'+ Derivate.
Range-Requests für Video/Audio: CDN zwischenspeichert Chunks.
Content-Negotiation: Halten Sie die Kardinalität des Schlüssels niedrig (Geräteklasse statt roher UA).

Beobachtbarkeit und SLO

Schlüsselmetriken

Hit-ratio (by bytes/requests) на edge/tier/shield.
p50/95/99 TTFB nach Region und Typ (Statik/API).
Fill-rate/Origin egress - wie viel geht zum Ursprung.
304 Rate und durchschnittliche Antwortgröße.
Fehlerbudget: Anteil der 'stale-if-error '/' SWR' -Ausgaben; Häufigkeit von Purge.

Beispiele für SLOs

„p95 TTFB“ Statik regional ≤ 120-150 ms, API GET Caching ≤ 200-250 ms.
Edge Hit-Ratio Statik ≥ 90%, Halbdynamik ≥ 60%.
Der Anteil der Antworten aus dem Stale-Zweig bei Fehlern ≤ 0. 5% in 30 Tagen.

Config-Spickzettel

Nginx (Reverse-Proxy vor CDN oder in Self-PoP)

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=CDN:512m max_size=100g inactive=7d;

map $args $clean_args {
"~(^    &)(utm_    gclid    fbclid) """; # default $ args simplified example;
}

server {
listen 443 ssl http2;
set $cache_key "$scheme$request_method$host$uri?$clean_args    $http_accept    $http_accept_encoding";
location /static/ {
proxy_cache CDN;
proxy_cache_key $cache_key;
proxy_ignore_headers Set-Cookie;
add_header Cache-Control "public, s-maxage=86400, max-age=3600, stale-while-revalidate=600" always;
proxy_pass https://origin_static;
}

location /api/public/ {
proxy_cache CDN;
proxy_cache_key $cache_key;
proxy_cache_valid 200 30s;
add_header Cache-Control "public, s-maxage=30, max-age=5, stale-while-revalidate=120, stale-if-error=600" always;
proxy_set_header If-None-Match $upstream_http_etag;
proxy_pass https://origin_api;
}
}

Envoy (SWR + negativer Cache, Konzept)

yaml http_filters:
- name: envoy. filters. http. cache typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. cache. v3. CacheConfig typed_config:
"@type": type. googleapis. com/envoy. extensions. cache. simple_http_cache. v3. SimpleHttpCacheConfig
Cache-Control/Surrogate-Control Header Cache Policies
We cache 5xx errors briefly via route/retry policy + local_rate_limit

Header für „schnelle“ Assets

Cache-Control: public, max-age=31536000, immutable
ETag: "hash"
Content-Encoding: br

Header für Semi-Dynamik (Kataloge)

Cache-Control: public, s-maxage=600, max-age=120, stale-while-revalidate=1800, stale-if-error=86400
Vary: Accept-Encoding, Accept

FinOps: So spart der Cache Geld

Egress origin ↓, weniger CPU/DB-Last → geringere Infrastrukturkosten.
Weniger Anfragen vor kostenpflichtigen Backends (search/index/images).
Zielkennzahl: $/p95-Reduktion und $/egress-Reduktion um 1 GB - Nachverfolgung des Post-Launch-Effekts.

Spezifität für iGaming/Fintech

Anbieter-/Asset-Verzeichnisse: versionierte Pfade + einjährige TTL.
Event/Turnier Landings: 1-5 min 's-maxage' + 'SWR' für 10-30 min; tag-purge beim Aktualisieren.
Liv-Seiten (Koeffizienten/Tabellen): Teilcache von JSON-Blöcken, kurze TTLs (5-30 s), für persönliche Blöcke - Client-Renderer.
PSP/Payment Endpoints: Nicht Caching, strenger „No-Store“; nur Verzeichnisse (BIN-Tabellen, Status) zwischenspeichern.
Antibot: Caching static/GET, „graue“ Routen für verdächtige ASNs; Lassen Sie' Vary 'nicht durch laute Überschriften.

Checkliste für die Implementierung

• Cacheschlüssel beschrieben: URL-Normalisierung, Liste zulässiger Query, 'Vary' nur nach Bedarf.
• Getrennte öffentliche/private Wege; privat - 'no-store' und bypass CDN.
• TTL-Leiter nach Inhaltstypen eingeführt; ist „SWR/if-error“ konfiguriert.
• tiered-cache + origin-shield; negative-cache 5xx (kurz) ist aktiviert.
• Es gibt Tag/URL Purge, Soft Purge; Integration mit CI/CD.
• Komprimierung (br/gzip), webbasierte Bildformate und Range-Antworten enthalten.
• Metriken: hit-ratio by layer, p95 TTFB, 304 rate, origin egress; Alerts für Ausfälle.
• Playbooks: Aufwärmen des Caches vor Peaks, Notfall-Purge, Origin-Degradation.

Typische Fehler

No-Versio-Assets mit einer großen TTL → „klebrige“ Bandles von Benutzern.
Exzessives' Vary'(nach 'User-Agent', alle Überschriften) → eine Explosion der Kardinalität und eine niedrige Trefferquote.
Zwischenspeicherung von 4xx/401/403/privaten Inhalten.
Das Fehlen von negativem Cache → eine Lawine von Anfragen nach degradiertem Ursprung.
Keine Tag-Purge → massive Punkt Purge und „Sturm“ Re-Fill.
Der Cache-Schlüssel enthält „verrauschte“ UTM/Refparameter.
Eine zu kurze TTL für die Statik → eine zusätzliche Belastung für CDN und Herkunft.

Mini-Playbooks

1) Aufwärmen des Caches vor dem Ereignis

1. Sammlung von Top-N-URLs nach Log → 2) Parallel Prefetch (Rate-Limited) nach Region → 3) Hit-Ratio-Check ↑ und p95 ↓.

2) Notfall Soft-Purge Katologen

1. Senden Sie' PURGE '/tag-clear → 2) CDN gibt stale und hintergrund zieht frisch → 3) Überprüfen Sie die Abwesenheit von spikes auf der Herkunft.

3) Ursprungsverweigerung

1. 'stale-if-error' hilft X Stunden → 2) Aktivieren Sie das Banner „technische Arbeit“ am Rand → 3) Durch Wiederherstellung - Ziel warm-up.

Ergebnis

Starke CDN-Strategie = richtiger Cache-Schlüssel + sinnvolle TTLs mit SWR/if-error + managed disability + tiered/shield + Beobachtbarkeit. Fixieren Sie Richtlinien in Header und IaC, messen Sie Hit-Ratio und P95, planen Sie das Aufwärmen für Peaks - und Benutzer erhalten immer eine schnelle Antwort, und der Ursprung bleibt auch in der heißesten Stunde am Leben.