Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Amazon ElastiCache (Valkey) für E-Commerce-Anwendungen

Eine E-Commerce-Anwendung profitiert von einer In-Memory-Cache-Schicht zwischen den Anwendungsservern und der Datenbank. Amazon, ElastiCache auf dem Valkey läuft, bietet eine Leselatenz von unter einer Millisekunde für Daten, auf die häufig zugegriffen wird — Produktkatalogeinträge, Inventarzählungen, Suchergebnisse und Benutzersitzungen —, wodurch die Datenbanklast reduziert und die Reaktionszeiten bei Datenverkehrsspitzen verbessert werden.

Cluster-Konfiguration

Wählen Sie einen Clustertyp, der auf Ihrem Datenvolumen, Ihren Durchsatzanforderungen und betrieblichen Präferenzen basiert.

Für die meisten E-Commerce-Anwendungen, die noch am Anfang stehen, bietet Serverless den einfachsten Weg zur Produktion. Migrieren Sie zu knotenbasierten Clustern, wenn Sie über vorhersehbare Datenverkehrsbasislinien verfügen und mehr Kontrolle über die Clustertopologie, die Knotentypen und das Skalierungsverhalten benötigen.

Wichtiges Design für Produktdaten

Entwerfen Sie Cache-Schlüssel so, dass sie vorhersehbar, debugbar und bereichsspezifisch sind, um Kollisionen zwischen Datentypen zu vermeiden.

Die wichtigsten bewährten Methoden für das Design:

TTL-Strategie nach Datentyp

Legen Sie TTL-Werte (Time-to-Live) fest, die darauf basieren, wie häufig sich Daten ändern und wie veraltet sie sein können, ohne das Kundenerlebnis zu beeinträchtigen.

Cache-aside Muster

Das Cache-Aside-Muster (auch Lazy Loading genannt) ist die gängigste Caching-Strategie für E-Commerce-Anwendungen. Ihre Anwendung überprüft zuerst den Cache und fragt die Datenbank nur ab, wenn der Cache fehlschlägt.

Pfad lesen (Pseudocode)

FUNCTION getProduct(productId):
    cacheKey = "product:" + productId

    // Step 1: Check the cache
    cachedValue = cache.GET(cacheKey)

    IF cachedValue exists:
        RETURN deserialize(cachedValue)    // Cache hit — sub-millisecond

    // Step 2: Cache miss — query database
    product = database.query("SELECT * FROM products WHERE id = ?", productId)

    IF product not found:
        RETURN null

    // Step 3: Write to cache with TTL
    cache.SET(cacheKey, serialize(product), EXPIRE = 300)    // 5 minutes

    RETURN product

Pfad schreiben (Pseudocode)

FUNCTION updateProduct(productId, updatedFields):
    // Step 1: Update the database (source of truth)
    database.update("UPDATE products SET ... WHERE id = ?", updatedFields, productId)

    // Step 2: Invalidate the cache (don't update it)
    cache.DELETE("product:" + productId)

    // Next read will trigger a cache miss and repopulate from database

Behandlung von Cache-Ausfällen

FUNCTION getProductWithFallback(productId):
    TRY:
        RETURN getProduct(productId)    // Normal cache-aside path
    CATCH cacheConnectionError:
        // Cache is unavailable — fall back to database directly
        RETURN database.query("SELECT * FROM products WHERE id = ?", productId)
        // Log the error, trigger an alarm, but don't fail the request

Entwerfen Sie Ihre Anwendung so, dass ein Cache-Ausfall die Leistung beeinträchtigt (langsamere Reaktionen), die Funktionalität jedoch nicht beeinträchtigt. Die Datenbank dient als Fallback.

Strategien zur Cache-Invalidierung

Durch die Invalidierung wird sichergestellt, dass Benutzer nach Aktualisierungen die aktuellen Daten sehen. Wählen Sie eine Strategie, die darauf basiert, wie schnell Änderungen sichtbar sein müssen.

Bei Marketplace-Anwendungen, die Amazon ebenfalls CloudFront als CDN-Ebene verwenden, koordinieren Sie die Invalidierung auf beiden Ebenen: Löschen Sie den ElastiCache Schlüssel und senden Sie eine CloudFront Cache-Invalidierung (oder Cache-Tag-Invalidierung), damit Benutzer aktualisierte Inhalte sowohl auf der Anwendungs- als auch auf der Edge-Ebene sehen.

Verbindungsverwaltung

Wichtige zu überwachende Kennzahlen

Häufig gestellte Fragen

Wann sollte ich serverlos und wann knotenbasiert verwenden?

Verwenden Sie Serverless, wenn Ihr Traffic unvorhersehbar ist (neuer Marktplatz, saisonale Spitzen), wenn Sie eine Kapazitätsplanung vermeiden möchten oder wenn Ihr Team nicht über Fachwissen im Caching-Betrieb verfügt. Wechseln Sie zu knotenbasiertem Datenverkehr, wenn Ihre Datenverkehrsmuster stabil sind, Sie eine genaue Kontrolle über das Sharding benötigen oder Ihr anhaltender Durchsatz die knotenbasierte Nutzung kostengünstiger macht.

Sollte ich Valkey oder Redis OSS verwenden?

Verwenden Sie Valkey für neue Bereitstellungen. Valkey ist die Standard-Engine für neue ElastiCache Cluster, ist vollständig kompatibel mit Redis OSS-Befehlen und Datenstrukturen und wird kontinuierlich weiterentwickelt. Bestehende Redis OSS-Cluster funktionieren weiterhin — migrieren Sie zu Valkey, wenn es Ihnen passt, indem Sie das direkte Engine-Upgrade verwenden.

Was passiert, wenn der Cache nicht verfügbar ist?

Ihre Anwendung sollte den Cache als Optimierung und nicht als Abhängigkeit behandeln. Wenn der Cache nicht verfügbar ist, greifen Sie auf die direkte Abfrage der Datenbank zurück. Die Antwortzeiten werden länger sein, aber die Anwendung bleibt funktionsfähig. Multi-AZ Wenn diese Option aktiviert ist, ist der Cache selten vollständig nicht verfügbar — ein Failover auf ein Replikat dauert in der Regel weniger als 30 Sekunden.

Wie schätze ich den Speicherbedarf ein?

Berechnen Sie: (Anzahl der einzelnen Elemente, die zwischengespeichert werden sollen) × (durchschnittliche Größe pro Element) × (Overhead-Faktor 1,2 für Valkey-Datenstrukturen). Der Overhead variiert je nach Objektgröße und Datentyp — kleinere Objekte haben einen proportional höheren Overhead. Beispiel: 100.000 Produkte mit jeweils 2 KB und 1,2-fachem Overhead entsprechen etwa 240 MB. Fügen Sie Sitzungsdaten, Suchergebnisse und Inventarzahlen hinzu. Beginnen Sie mit dem Headroom (verwenden Sie 60% des verfügbaren Speichers als Ziel) und beobachten Sie die DatabaseMemoryUsagePercentage Kennzahl, um Anpassungen vorzunehmen.