Ein Request durchläuft mehrere Cache-Schichten, wobei jede näher am Benutzer liegt und schneller antwortet, aber weniger speichert. Die Idee ist, so nah wie möglich beim Client zu antworten und nur zum Origin durchzufallen, wenn keine upstream Schicht die Response bereitstellen kann.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag gesteuert; Ressourcen erhalten oft lange TTLs (Tage–Jahre) mit gehashten Dateinamen.for each layer outward → inward:
if layer has fresh copy → return it (stop here) // a hit; cheapest possible
else → ask the next layer in // a miss; falls through
origin (app + DB) → does the real work, fills caches on the way back out
Jede Schicht tauscht Aktualität gegen Geschwindigkeit: äußere Schichten sind am schnellsten, aber wahrscheinlich veraltet, also verwenden Sie lange TTLs + Content-Hashing für wirklich statische Inhalte und kurze TTLs + Invalidierung für dynamische.
Die meiste Latenzreduzierung und Lastverteilung in einem Web-Stack kommt vom Caching in der richtigen Schicht. Zu wissen, was jede Schicht speichert und ihre typische TTL, ermöglicht es Ihnen, einen Cache dort zu platzieren, wo er tatsächlich hilft, veraltete Daten zu vermeiden und zu begründen, warum eine Änderung nicht erscheint (welche Schicht serviert immer noch eine alte Kopie).