Microsoft AZ-204: Azure Caching, CDN und Performance — Lernleitfaden

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Teil des Microsoft Azure Developer Associate AZ-204 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Schnelle, zuverlässige Benutzererfahrungen in Azure hängen davon ab, Inhalte und Zustände nahe bei den Benutzern zu platzieren, die Last auf dem Ursprungsserver zu minimieren und Ausfälle elegant zu behandeln. Azure Cache for Redis, Azure CDN und Azure Front Door bieten zusammen In-Memory-Beschleunigung, Edge-Caching und globales Anycast-Routing mit Sicherheit. Die Beherrschung von Redis-Datenstrukturen und Verbindungsmustern, CDN-Profilen und Caching-Semantiken sowie Front Door-Routing und Health Probes ermöglicht es Ihnen, latenzarme und widerstandsfähige Anwendungen zu entwerfen.

Azure Cache for Redis: Tarife, Datenstrukturen, Eviction und Muster

Azure Cache for Redis ist ein verwalteter Redis-Dienst, der Datenzugriff im Sub-Millisekundenbereich bietet und gängige Redis-Datenstrukturen sowie erweiterte Funktionen in höheren Tarifen unterstützt.

Tarife:

Basic: Single-Node-Cache ohne SLA und ohne Datenreplikation. Gut für Dev/Test und unkritische Workloads. Keine Datenpersistenz, kein Clustering, keine VNet-Integration.
Standard: Zwei-Knoten-Primär/Replikat-Konfiguration mit automatischem Failover und einem SLA. Geeignet für die Produktion. Unterstützt das Hoch- und Herunterskalieren mit minimaler Unterbrechung, aber kein Clustering oder Persistenz.
Premium: Höhere Leistung und Durchsatz, größere Cache-Größen, Redis-Persistenz (RDB und AOF), Clustering (Sharding) für horizontale Skalierung, Integration in virtuelle Netzwerke, Zonenredundanz (in unterstützten Regionen) und Geo-Replikation für DR. Unterstützt auch geplante Patching-Fenster und erweiterte Sicherheit.

Datenstrukturen und ihre Anwendungsfälle:

Strings: Einfache Schlüssel-Wert-Paare, Zähler, JSON-Blobs; atomare INCR/DECR-Operationen für Ratenbegrenzung und Zähler.
Hashes: Speichern von Objektfeldern (z. B. Benutzerprofil) als einzelner Schlüssel mit Feld-Wert-Paaren für partielle Updates und Speichereffizienz.
Lists: Warteschlangen oder Stapel, geordnet nach Einfügereihenfolge; Verwendung mit LPUSH/BRPOP für einfache Arbeitswarteschlangen.
Sets: Eindeutige Sammlungen; Verwendung für Tags, Mitgliedschaftsprüfungen, Schnittmengen.
Sorted Sets: Ranglisten mit Scores; ideal für Leaderboards und zeitlich geordnete Ereignisse.
Bitmaps/Bitfields: Kompaktes Verfolgen von booleschen Flags und Zählern über Positionen.
HyperLogLog: Approximative Kardinalität (Anzahl eindeutiger Elemente) mit festem Speicherverbrauch.
Geospatial: Speichern und Abfragen von Breiten- und Längengradkoordinaten, Umkreissuchen.
Streams: Append-only-Log für die Aufnahme von Ereignissen und Consumer-Gruppen.

Eviction-Richtlinien (angewendet, wenn maxmemory erreicht ist):

volatile-lru: Entfernt die am längsten nicht verwendeten Schlüssel mit einer Ablaufzeit (Standard bei Azure Cache for Redis).
allkeys-lru: Entfernt die am längsten nicht verwendeten Schlüssel, unabhängig von der Ablaufzeit.
volatile-ttl: Entfernt Schlüssel mit der kürzesten verbleibenden Ablaufzeit.
volatile-random / allkeys-random: Entfernt zufällige Schlüssel, beschränkt auf ablaufende oder alle Schlüssel.
noeviction: Keine Schlüssel entfernen; Schreibbefehle, die Speicher hinzufügen würden, schlagen mit einem Fehler fehl.
volatile-lfu / allkeys-lfu: Varianten zur Entfernung der am seltensten verwendeten Schlüssel (für neuere Redis-Versionen).

Wählen Sie die Eviction-Richtlinie basierend auf der Kritikalität der Daten und den Zugriffsmustern. Für Caches liefern allkeys-lru oder allkeys-lfu die besten Trefferquoten. Für gemischte Speicher mit sorgfältig gesetzten Ablaufzeiten können volatile-ttl oder volatile-lru Ihre TTLs berücksichtigen.

Häufige Anwendungsfälle:

Session Caching: Speichern des Benutzer-Sitzungszustands über IDistributedCache oder Session-Middleware. Halten Sie die Schlüssel klein, verwenden Sie eine TTL, die auf das Session-Timeout abgestimmt ist, und aktivieren Sie bei Bedarf Session-Affinität am Edge.
Output Caching: Cachen von gerenderten Seitenfragmenten oder vollständigen Antworten, mit Schlüsseln basierend auf Route und Benutzersegment. Invalidierung bei Inhaltsänderungen durch Schlüssel-Versioning oder explizites DEL.
Pub/Sub: Nachrichtenübermittlung in nahezu Echtzeit für Benachrichtigungen oder Fan-Out zur Cache-Invalidierung. Verwenden Sie Kanäle, um Änderungen an mehrere Abonnenten zu senden.
Leaderboards: Sorted Sets mit Scores für Ranglisten; ZADD/ZREVRANGE zum Aktualisieren und Lesen der Top-N; verwenden Sie sekundäre Sorted Sets für zeitfensterbasierte Ranglisten.

Verbindung zu Azure Redis: Verbindungszeichenfolgen, StackExchange.Redis und Resilienz

Verbindungsendpunkte und Schlüssel werden im Azure-Portal unter „Zugriffsschlüssel“ bereitgestellt. Die primäre Verbindungszeichenfolge enthält Host, Port, TLS und Passwort (zum Beispiel: contoso.redis.cache.windows.net:6380,password=…;ssl=True;abortConnect=False). Verwenden Sie in der Produktion immer TLS auf Port 6380.

Best Practices für StackExchange.Redis:

Verwenden Sie einen einzigen, langlebigen ConnectionMultiplexer pro Prozess. Er ist threadsicher und multiplext Anfragen effizient. Erstellen Sie ihn einmal, speichern Sie ihn in einem statischen oder DI-Container und verwenden Sie ihn wieder.
Konfigurationsoptionen: Setzen Sie AbortOnConnectFail=false für Toleranz gegenüber Cloud-Failover; setzen Sie ConnectRetry und ConnectTimeout für transiente Probleme; SyncTimeout auf den Workload abstimmen; KeepAlive, um NAT-Pinholes aufrechtzuerhalten. Beispieloptionen in Textform: ssl=True, abortConnect=False, connectRetry=5, connectTimeout=5000.
Verwenden Sie asynchrone Methoden, um eine Überlastung des Thread-Pools unter Last zu vermeiden. IDatabase-Methoden (StringGetAsync, HashSetAsync, SortedSetAddAsync) sind nicht blockierend.
Behandeln Sie Resilienz-Ereignisse: Abonnieren Sie die Ereignisse ConnectionFailed, ConnectionRestored und ConfigurationChanged, um Topologieänderungen und Failover zu protokollieren und zu beobachten. StackExchange.Redis löst bei einem Failover automatisch den primären Endpunkt neu auf.
Vermeiden Sie langlaufende Lua-Skripte und aufwendige Transaktionen; bevorzugen Sie kleine, atomare Befehle. Pipelining erfolgt natürlich über den Multiplexer; vermeiden Sie übermäßiges Batching, das zu Timeouts führen könnte.
Timeouts und Wiederholungsversuche: Führen Sie keine blinden Wiederholungsversuche für nicht-idempotente Befehle durch. Verwenden Sie idempotente Muster oder Write-Through-Warteschlangen für kritische Schreibvorgänge.
Serialisierung: Speichern Sie kompakte Payloads (z. B. MessagePack), um den Netzwerkverkehr und den Speicherverbrauch zu minimieren. Vermeiden Sie riesige Werte; bevorzugen Sie Hashes mit Zugriff auf Feldebene.
Schlüsselbenennung: Präfix nach App/Umgebung (prod:session:{userId}), um Kollisionen zu vermeiden und Massenoperationen sowie Bereinigungen zu vereinfachen.
Sicherheit: Rotieren Sie Zugriffsschlüssel, beschränken Sie den Zugriff über VNet (Premium) und ziehen Sie Private Link für privaten Zugriff in Betracht. Setzen Sie „Zugriff nur über SSL zulassen“ in der Produktion nicht auf „false“.

Azure CDN: Profile, Endpunkte, Ursprünge, Optimierung und Aktualität von Inhalten

Azure CDN speichert statische Inhalte in Edge-POPs zwischen, um die Latenz zu verringern und die Last am Ursprung zu reduzieren. Ein CDN-Profil gruppiert Endpunkte und den Tarif/Anbieter; ein Endpunkt definiert den Edge-Hostnamen und verbindet sich mit einem oder mehreren Ursprüngen.

Profile und Endpunkte:

Erstellen Sie einen oder mehrere Endpunkte pro Anwendung oder Umgebung unter einem Profil. Jeder Endpunkt hat seinen eigenen Edge-Hostnamen (z. B. app.azureedge.net), den Sie benutzerdefinierten Domänen mit TLS zuordnen.
Verwenden Sie separate Profile, um die Abrechnung zu isolieren oder bei Bedarf unterschiedliche Anbieter/Funktionen anzuwenden.

Ursprungstypen:

Azure Blob Storage: Ideal für statische Websites und große Mediendateien. Aktivieren Sie „Statische Website“ oder ordnen Sie es einem Container zu; stellen Sie korrekte MIME-Typen und Cache-Header sicher.
App Service: Verwenden Sie es für dynamische Inhalte oder REST-APIs, bei denen ausgewählte Antworten zwischengespeichert werden können. Konfigurieren Sie den Origin-Host-Header auf den Hostnamen Ihrer App und stellen Sie HTTPS sicher.
Benutzerdefinierter Ursprung: Jeder öffentlich erreichbare HTTP(S)-Endpunkt, einschließlich lokaler Systeme über eine öffentliche IP oder einen Reverse-Proxy.

Optimierungstypen (werden bei der Erstellung des Endpunkts angewendet):

Allgemeine Webbereitstellung: Ausgewogen für viele kleine/mittlere Assets (HTML, CSS, JS, Bilder) mit breiter POP-Abdeckung.
Download großer Dateien: Optimiert für große Dateien mit Abstimmung von Bereichsanforderungen (Range Requests), Verbindungsmanagement und durchsatzorientierten Einstellungen.
Video-Streaming: Optimiert für Progressive Download oder die Bereitstellung von HLS/DASH-Segmenten, wobei das Caching von Segmenten effizient gehalten und Byte-Range-Anfragen berücksichtigt werden.

Caching-Regeln und Bereinigung (Purging):

Globale und benutzerdefinierte Caching-Regeln ermöglichen Ihnen die Steuerung von TTLs basierend auf Pfad, Dateierweiterung, Anfragemethode und dem Verhalten von Abfragezeichenfolgen. In den Standard-Tarifen konfigurieren Sie Regeln in den Caching-Einstellungen des Endpunkts; Premium fügt erweiterte Regel-Engines hinzu.
Bereinigen Sie ungültige Inhalte nach Pfad mit Platzhaltern (z. B. /images/*) über das Portal, die CLI oder die REST-API. Bereinigungen (Purges) werden über alle POPs verteilt; verwenden Sie gezielte Bereinigungen, um den „Blast Radius“ (Schadensradius) zu minimieren. Premium-Tarife unterstützen Preload zum Vorwärmen der Caches.

Steuerelemente für die Aktualität von Inhalten:

TTL: Das CDN berücksichtigt standardmäßig die Header Cache-Control und Expires vom Ursprung. Sie können mit Regeln minimale/maximale TTLs überschreiben oder festlegen. Für unveränderliche Assets liefern Sie

undefined

aus, um die Trefferquoten zu maximieren.

Cache-Control-Direktiven: no-store und private werden vom CDN nicht zwischengespeichert; must-revalidate und s-maxage ermöglichen eine feingranulare Steuerung des Shared Cache. Bevorzugen Sie s-maxage für CDN-spezifische TTLs, während Sie max-age für Browser konservativ halten.
Verhalten beim Caching von Abfragezeichenfolgen: Wählen Sie, ob Abfragezeichenfolgen ignoriert werden sollen (ein einzelnes zwischengespeichertes Objekt pro Pfad), jede eindeutige URL zwischengespeichert werden soll (jede Kombination von Abfragezeichenfolgen wird separat zwischengespeichert) oder der Cache bei einer Abfragezeichenfolge umgangen werden soll. Für versionierte Assets (z. B. app.css?v=hash) speichern Sie jede eindeutige URL zwischen. Für Analyseparameter (utm_) ignorieren Sie Abfragezeichenfolgen, um die Trefferquoten zu verbessern.
Vary und Komprimierung: Stellen Sie sicher, dass bei der Komprimierung Vary: Accept-Encoding gesetzt ist; das CDN speichert separate Varianten pro Vary-Schlüssel zwischen. Aktivieren Sie die CDN-Komprimierung für Text-Assets, um die Bandbreite zu reduzieren.

Azure Front Door: Globales Routing, Integrität, Sicherheit und Affinität

Azure Front Door bietet Anycast-basierten, globalen Layer-7-Lastausgleich, dynamische Website-Beschleunigung und eine integrierte WAF. Es ergänzt ein CDN, indem es dynamischen Datenverkehr weiterleitet und schützt, während es bei Standard/Premium optional statische Inhalte zwischenspeichert.

Routing-Regeln:

Gleichen eingehende Hostnamen und Pfadmuster ab und leiten den Verkehr an eine Ursprungsgruppe (Backend-Pool) weiter. Wenden Sie pro Regel Pfad-Umschreibungen, Header-Transformationen, Umleitungen und Protokolleinstellungen an.
Konfigurieren Sie das Caching auf der Route (Standard/Premium) für das Edge-Caching von statischen oder semi-statischen Assets, wenn Sie eine engere Kontrolle am Anwendungs-Edge wünschen.
Nutzen Sie prioritätsbasiertes Failover und gewichteten Lastausgleich über Ursprünge hinweg, optional mit Geo-Filterung für regionsspezifisches Routing.

Integritätstests und Backend-Integrität:

Definieren Sie Testpfad, Protokoll, Intervall und erwartete HTTP-Statuscodes. Die Tests werden von mehreren Edge-Standorten aus ausgeführt, um die Integrität des Ursprungs zu bestimmen.
Front Door nutzt den Integritätsstatus, um den Datenverkehr zu fehlerfreien Ursprüngen mit geringer Latenz zu leiten. Passen Sie Timeouts und Stichprobengröße an, um „Flapping“ zu vermeiden; stellen Sie sicher, dass der Test-Endpunkt schlank und nicht zwischengespeichert ist.

WAF-Integration:

Hängen Sie eine WAF-Richtlinie an Ihre Front Door an, um verwaltete Regelsätze für gängige Web-Schwachstellen zu erzwingen und benutzerdefinierte Regeln für IP-Einschränkungen, Geoblocking oder Limits für die Anforderungsgröße hinzuzufügen.
Verwenden Sie Bot-Schutz und Ratenbegrenzung, um missbräuchlichen Datenverkehr am Edge abzufangen und so die Kapazität des Ursprungs zu schonen.

Sitzungsaffinität:

Aktivieren Sie die Sitzungsaffinität, wenn Ihre Anwendung erfordert, dass aufeinanderfolgende Anfragen denselben Backend-Server erreichen (z. B. bei nicht verteiltem Sitzungszustand). Front Door fügt ein Affinitäts-Cookie ein und leitet nachfolgende Anfragen derselben Sitzung an das ausgewählte Backend innerhalb einer Routing-Regel weiter.
Bevorzugen Sie zustandslose Designs oder einen durch Redis gestützten Sitzungszustand, um Affinität nach Möglichkeit zu vermeiden; falls sie verwendet wird, grenzen Sie die Affinität sorgfältig ein und legen Sie angemessene Cookie-TTLs fest.

Zusammenspiel mit CDN:

Ein CDN sollte statische Assets (Bilder, Skripte, Medien) mit langen TTLs ausliefern; Front Door leitet dynamische Anfragen mit WAF, TLS-Terminierung und pfadbasiertem Routing weiter. Diese Aufteilung maximiert die Cache-Trefferquoten und minimiert die dynamische Latenz.
Für APIs oder Seiten, die nicht zwischengespeichert werden können, halten Sie die TTL niedrig oder umgehen Sie das Caching; für semi-statisches HTML ziehen Sie kurze TTLs mit Workflows in Betracht, die bei Änderungen eine Bereinigung durchführen (Purge-on-Change).

Praktisches Problemszenario

Mozilla startet eine globale Microsite zur Entdeckung von Add-ons, bei der während der Veröffentlichungen hohe Lastspitzen erwartet werden. Sie benötigen eine schnelle Auslieferung statischer Assets, resiliente dynamische APIs und sichere, latenzarme Benutzerinteraktionen weltweit.

Front Door für globalen Einstiegspunkt und Sicherheit

Erstellen Sie ein Front Door Standard-Profil mit einer benutzerdefinierten Domain und verwaltetem TLS. Definieren Sie Routing-Regeln: /api/* zur API-Ursprungsgruppe des App Service und /* zum Hostnamen des CDN-Endpunkts.
Warum: Anycast-Routing leitet Benutzer zum nächstgelegenen Edge-Standort; die WAF bei Front Door blockiert bösartige Muster, bevor sie die Ursprünge erreichen; pfadbasiertes Routing trennt dynamischen und statischen Datenverkehr sauber.

WAF-Richtlinie und Ratenbegrenzung

Hängen Sie eine WAF-Richtlinie mit aktivierten verwalteten Regelsätzen und einer benutzerdefinierten Regel an, um übermäßige POST-Anfragen an /api/search zu drosseln.
Warum: Schützt APIs vor Angriffen der OWASP-Klasse und missbräuchlichen Clients und schont die Kapazität des Ursprungs bei Lastspitzen.

Integritätstests und Ursprungsgruppen

Konfigurieren Sie die API-Ursprungsgruppe mit zwei App Service-Instanzen in verschiedenen Regionen. Verwenden Sie Integritätstests für /healthz mit dem erwarteten Status 200 und einem Intervall von 10 Sekunden. Setzen Sie eine Region auf Priorität 1 und die andere auf Priorität 2, mit Failover.
Warum: Stellt ein automatisches regionales Failover sicher, falls die primäre Region ausfällt; die Tests erkennen die Integrität unabhängig von zwischengespeicherten Antworten.

Redis-gestützte Sitzungen und Output-Caching

Stellen Sie Azure Cache for Redis Standard bereit und integrieren Sie die API mit IDistributedCache, um minimalen Sitzungszustand und kurzlebige Ausgabefragmente für häufige API-Antworten (z. B. Listen beliebter Add-ons) mit TTLs von 60–300 Sekunden zu speichern.
Warum: Reduziert die API-Latenz und die Datenbanklast, während der Zustand von der Web-Ebene ferngehalten wird; kurze TTLs gewährleisten die Aktualität ohne manuelle Invalidierung.

Redis-Datenstrukturen für Ranglisten

Verwenden Sie ein sortiertes Redis-Set pro Kategorie (z. B. addons:top:{category}), um downloadbasierte Ranglisten zu führen. Aktualisieren Sie die Punktzahlen asynchron über einen Queue-Consumer und stellen Sie Lese-APIs bereit, die die Top-N-Einträge lesen.
Warum: Sortierte Sets bieten O(log n)-Updates und schnelle Bereichsabfragen, perfekt für Echtzeit-Ranglisten mit hoher Lese-Parallelität.

Verbindungswiderstandsfähigkeit mit StackExchange.Redis

Initialisieren Sie einen Singleton ConnectionMultiplexer mit ssl=True, abortConnect=False, connectRetry=5 und sinnvollen Timeouts. Behandeln Sie ConnectionFailed/Restored-Ereignisse zur Beobachtbarkeit und setzen Sie SyncTimeout hoch genug für Lastspitzen, während Sie asynchrone APIs verwenden.
Warum: Gewährleistet eine nahtlose Failover-Behandlung und vermeidet prozessweite Ausfälle bei vorübergehenden Netzwerkereignissen oder Redis-Failovern.

CDN für statische Assets mit aggressivem Caching

Erstellen Sie ein Azure CDN-Profil und einen Endpunkt, der für die allgemeine Web-Bereitstellung optimiert ist, mit der statischen Website des Speicherkontos als Ursprung. Konfigurieren Sie Caching-Regeln so, dass die Ursprungs-Header berücksichtigt werden, aber überschreiben Sie diese für /static/* mit einer TTL von 7 Tagen, und aktivieren Sie die Komprimierung. Setzen Sie das Caching von Abfragezeichenfolgen auf „Cache every unique URL“ und versehen Sie Assets mit einem Fingerprint (app.css?v=hash).
Warum: Edge-Caching liefert Assets weltweit schnell aus; Fingerprinting ermöglicht lange TTLs mit sofortigen Updates bei Deployments; Komprimierung reduziert die Übertragungsgrößen.

Purge-Prozess in CI/CD

Fügen Sie einen Deployment-Schritt hinzu, der CDN-Pfade für HTML- und JSON-Manifeste bei einer Veröffentlichung bereinigt (purged) (z. B. /index.html, /manifest/*.json) und kritische Seiten vorlädt, um die Caches in unterstützten Tiers aufzuwärmen.
Warum: Stellt sicher, dass Benutzer schnell frisches HTML erhalten, während unveränderliche Assets zwischengespeichert bleiben; das Vorladen reduziert die Kaltstart-Latenz nach dem Deployment.

Front Door-Sitzungsaffinität nur wo erforderlich

Halten Sie APIs zustandslos und verlassen Sie sich für den Sitzungszustand auf Redis; deaktivieren Sie die Front Door-Sitzungsaffinität für /api/-Routen. Für ein älteres Admin-Tool, das Affinität erfordert, aktivieren Sie diese für /admin/ mit einer kurzen TTL.
Warum: Maximiert die Lastverteilung und Cache-Fähigkeit für die meisten Benutzer, während die Affinität auf den minimal erforderlichen Bereich beschränkt wird.

Diese Architektur verwendet Front Door für sicheres, intelligentes Edge-Routing und WAF, Azure CDN für die Bereitstellung statischer Inhalte mit hoher Trefferquote und präziser Aktualitätskontrolle und Azure Cache for Redis, um Lese-Hotspots auszulagern, latenzarme Sitzungs- und Ranglistendaten zu verwalten und Lastspitzen elegant abzufangen.

← Azure: Ereignis- und nachrichtenbasierte Lösungen · Alle Domänen · Azure-Überwachung →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →