App braucht einen Cache? Azure Managed Redis erstellen

Kunden rufen wiederholt dieselben Produktdetails ab. Jede Anfrage erneut aus der Datenbank zu beantworten verursacht Wartezeit und wiederholte Arbeit. Ein Cache hält eine temporäre Kopie im Arbeitsspeicher für schnelle Zugriffe. Azure Managed Redis stellt diesen gemeinsamen Cache für mehrere App-Instanzen bereit und ist Azures aktueller Dienst für neue Redis-Bereitstellungen.

Cache erstellen

Suche im Azure-Portal Azure Managed Redis → Create:

Resource group: rg-cloudtrips-redis-test-fc (neu)
Name: redis-ctappfc
Region: France Central
Data tier: In-memory
Cache size: 0.5 GB, falls verfügbar
Performance: Balanced
High availability: Disabled für diese Übung

Wähle die kleinste verfügbare Balanced-Größe und prüfe den Preis. Deaktivierte Hochverfügbarkeit passt zu dieser temporären Übung; produktive Caches profitieren von Replikaten.

Aktiviere unter Networking öffentlichen Zugriff für die lokale Verbindung. Lasse Active geo-replication deaktiviert. Wähle unter Advanced das Clustering Enterprise und aktiviere Access keys authentication für die Übung. Behalte TLS-Verschlüsselung bei. Wähle Review + create → Create.

Öffne nach der Bereitstellung Overview und warte auf Running. Beschränke unter Settings → Firewall den Zugriff auf deine aktuelle öffentliche IP mit identischer Start- und Endadresse und speichere.

Prüfe Running, die gewählte Größe und den Hostnamen. Kopiere den tatsächlichen Endpunkt von dieser Seite; Azure Managed Redis verwendet Port 10000.

Verbinden und einen Wert speichern

Installiere Redis Insight für deinen Computer. Wähle Connect existing database und verwende das manuelle Verbindungsformular:

Host: aus Azure Overview kopierter Endpunkt
Port: 10000
Username: default
Password: primärer Zugriffsschlüssel
TLS: Enabled

Den Schlüssel findest du unter Settings → Authentication → Access keys; aktiviere dort die Schlüssel-Authentifizierung, falls sie noch deaktiviert ist. Trage ihn ausschließlich im Passwortfeld ein. Behalte die TLS-Zertifikatsprüfung aktiviert, speichere und öffne die Verbindung. Bevorzuge für Anwendungsbereitstellungen Microsoft-Entra-ID-Authentifizierung.

Wähle im Browser von Redis Insight Add key, den Typ String und diese Werte:

Key: product:1
Value: Notebook | price 12.50
TTL: 120 Sekunden

Speichere den Schlüssel und wähle ihn im Browser aus.

Prüfe den Wert Notebook | price 12.50. TTL (Time To Live) ist die verbleibende Lebensdauer in Sekunden und sinkt nach dem Speichern. Dieser manuell gespeicherte Wert steht für Produktdetails, die eine App nach einer Datenbankabfrage zwischenspeichern könnte.

Ablauf prüfen

Warte, bis seit dem Speichern mehr als 120 Sekunden vergangen sind. Aktualisiere die Schlüsselliste und suche nach product:1.

Erwarte ein leeres Ergebnis für diesen Schlüssel. Redis hat die Cache-Kopie ablaufen lassen. Beim Cache-aside-Muster prüft eine App zuerst Redis; fehlt der Eintrag, liest sie die Datenbank und speichert eine frische Kopie mit TTL. Die Datenbank bleibt die maßgebliche Datenquelle. Bei Produktänderungen kann die App den Cache-Wert außerdem aktualisieren oder entfernen, damit Leser schneller aktuelle Daten erhalten.

Was passiert bei vollem Speicher?

Weitere Produkte können den verfügbaren Speicher füllen, bevor ihre TTL abläuft. Eine Eviction Policy bestimmt, welche Schlüssel Redis entfernt, um Platz zu schaffen. TTL steuert den zeitlichen Ablauf; Eviction reagiert auf Speicherdruck.

Richtlinie	Verhalten	Wann verwenden?
allkeys-lru	Entfernt am längsten ungenutzte Schlüssel (Least Recently Used).	Allgemeines Caching, wenn sich jeder Wert erneut laden lässt.
allkeys-lfu	Entfernt am seltensten verwendete Schlüssel (Least Frequently Used).	Dauerhaft beliebte Produkte im Speicher halten.
volatile-lru	Entfernt am längsten ungenutzte Schlüssel unter denen mit TTL.	Nur ablaufende Schlüssel zur Verdrängung zulassen; Standard von Azure Managed Redis.
volatile-ttl	Entfernt ablaufende Schlüssel mit der kürzesten verbleibenden TTL.	Werte bevorzugen, deren Ablauf ohnehin kurz bevorsteht.
noeviction	Behält Schlüssel und weist Schreibvorgänge mit zusätzlichem Speicherbedarf bei vollem Speicher zurück.	Apps, die Fehler wegen voller Caches ausdrücklich behandeln.

Für einen Produktcache, dessen Werte erneut aus der Datenbank geladen werden können, ist allkeys-lru ein praktischer Ausgangspunkt. Bei Volatile-Richtlinien brauchen verdrängbare Schlüssel eine TTL; fehlen solche Schlüssel, können speichervergrößernde Schreibvorgänge scheitern. Ablauf, ausdrückliches Löschen und Ausfälle können auch bei noeviction Daten entfernen.

Aufräumen

Behalte den Cache für den nächsten Trip oder lösche rg-cloudtrips-redis-test-fc. Das Schließen von Redis Insight und abgelaufene Schlüssel lassen den bereitgestellten Cache kostenpflichtig bestehen.