Designüberlegungen

Fehlerbehandlung: Wenn der Cache aus irgendeinem Grund nicht verfügbar ist, sollte die Anwendung so vorgehen, als ob es sich bei allen Elementen um Cache-Fehlschläge handelt. Das Vorhandensein der Cache-Ebene sollte einer Anwendung keine zusätzliche Fragilität verleihen.

TTL: Es ist möglich, einen einzigen TTL-Wert für alle Cache-Einträge zu konfigurieren oder je nach Eintrag unterschiedliche TTL-Werte zu verwenden (z. B., get_itemquery, oder Cache). scan Es ist auch möglich, einen anderen TTL-Wert für negative Cache-Einträge (Anfragen, die keine Elemente zurückgegeben haben) zu verwenden.

Verbrauchte Kapazität: Wenn Sie eine zwischengespeicherte Antwort zurückgeben, empfehlen wir Ihnen, die ConsumedCapacity Metriken in der Antwort so anzupassen, dass kein Leseverbrauch mehr verwendet wird.

Entfernung von Antwort-Metadaten: Sie sollten auch den ResponseMetadata Abschnitt in der Antwort entfernen. Dadurch wird das Risiko vermieden, dass jemand eine sieht RequestId und denkt, dass sie aktuell ist, obwohl sie tatsächlich von Stunden zuvor war.

Hinzufügen von Cache-Metadaten: Es ist hilfreich, der Antwort einen CacheMetadata Abschnitt hinzuzufügen. In diesem Abschnitt können die Zeit angegeben werden, zu der der Wert gespeichert wurde (nützlich, um die Veralterung zu messen) sowie die Client-Bibliothek und Version, in der der Wert gespeichert wurde (was nützlich sein kann, wenn ein nahtloses Upgrade von einer Version auf eine andere durchgeführt wird, bei der sich das Format ändert).

Ermitteln des Tabellenschemas: Um den Primärschlüssel aus einem Schreibvorgang für die Cache-Invalidierung zu ermitteln, müssen Sie das Schema der Tabelle kennen. Sie können diese Informationen abrufen, indem Sie für jede Tabelle einen describe_table Aufruf und einen Langzeit-Cache ElastiCache bei der ersten Verwendung (nur einmal) verwenden.

Die Clients akzeptieren statt konstruieren: Ein Vorteil beim Akzeptieren der DynamoDB- und Redis-Clientinstanzen im Konstruktor (anstatt sie innerhalb des Shim auf der Grundlage übergebener Parameter zu erstellen) besteht darin, dass der Aufrufer des Konstruktors Details bestimmen kann, z. B. ob gesetzt werden soll. read_from_replicas=True

Namespace-Funktion: Es kann praktisch sein, einen optionalen Namespace im Konstruktor zu unterstützen, der alle Ihre Cache-Lese- und Schreibvorgänge in diesen Namespace isoliert. Die Verwendung eines Namespaces ist ideal für Tests, da jeder Lauf mit einem anderen Namespace anscheinend mit einem leeren Cache beginnt und keine Nebenwirkungen wie bei früheren Ausführungen hat. Sie könnten auch das Leeren des gesamten Caches in der Produktion simulieren, indem Sie einfach den Namespace ändern. Dies kann implementiert werden, indem jedem Suchschlüssel automatisch ein Präfix hinzugefügt wird.

Scan-Caching: Es ist schwierig zu wissen, ob scan Anrufe zwischengespeichert werden sollen. Wenn Sie einen einmaligen vollständigen Tabellenscan durchführen, möchten Sie nicht, dass der Cache mit großen Seiten gescannter Daten gefüllt wird, die kein zweites Mal gelesen werden. Andererseits führen viele Workloads wiederholte Scans durch, insbesondere bei kleineren Tabellen, um mehreren nachgeschalteten Benutzern die neuesten vollständigen Tabellendaten zur Verfügung zu stellen. Ein Kompromiss wäre die Implementierung eines Systems, bei dem zwei Aufrufe entgegengenommen werden und jeder Anruf dieselbe Signatur hat (innerhalb des TTL-Zeitraums), sodass die resultierende Scan-Antwort zwischengespeichert wird. Dadurch wird vermieden, dass der Cache während eines einmaligen vollständigen Tabellenscans gefüllt wird, und es werden enge Scanschleifen ermöglicht, um die Vorteile des Zwischenspeichers zu nutzen. Beim ersten Scan wird ein kleiner Platzhalter in den Cache eingefügt, um die Anfrage als einmal gestellt zu kennzeichnen. Beim zweiten Scan wird der Token-Wert durch die tatsächliche Nutzlast ersetzt, die bis zu 1 MB groß sein kann.