Allgemeine Best Practices - Amazon ElastiCache

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.

Allgemeine Best Practices

Im Folgenden finden Sie Informationen zu bewährten Methoden für die Verwendung der darin enthaltenen Valkey-, Redis OSS - und Memcached-Schnittstellen. ElastiCache

  • Verwenden Sie Konfigurationen mit aktiviertem Clustermodus — Mit aktiviertem Clustermodus kann der Cache horizontal skaliert werden, um mehr Speicherplatz und Durchsatz zu erzielen als bei einer deaktivierten Konfiguration im Clustermodus. ElastiCache Serverless ist nur in einer Konfiguration mit aktiviertem Clustermodus verfügbar.

  • Verwenden Sie langlebige Verbindungen — Das Erstellen einer neuen Verbindung ist teuer und beansprucht Zeit und CPU Ressourcen aus dem Cache. Verwenden Sie Verbindungen nach Möglichkeit wieder (z. B. mit Verbindungspooling), um diese Kosten für viele Befehle zu amortisieren.

  • Aus Replikaten lesen — Wenn Sie ElastiCache serverlose Systeme verwenden oder Read Replicas (selbst entworfene Cluster) bereitgestellt haben, können Sie Lesevorgänge direkt an Replikate senden, um eine bessere Skalierbarkeit und/oder eine geringere Latenz zu erreichen. Lesevorgänge aus Replikaten sind mit dem Primärknoten letztendlich konsistent.

    Vermeiden Sie es, in einem selbst entworfenen Cluster Leseanforderungen an eine einzelne Read Replica weiterzuleiten, da Lesevorgänge möglicherweise vorübergehend nicht verfügbar sind, wenn der Knoten ausfällt. Konfigurieren Sie Ihren Client entweder so, dass Leseanfragen an mindestens zwei Read Replicas weitergeleitet werden oder Lesevorgänge an ein einzelnes Replikat und den Primärknoten weitergeleitet werden.

    Im ElastiCache serverlosen Modus werden beim Lesen vom Replikat-Port (6380) die Lesevorgänge nach Möglichkeit in die lokale Availability Zone des Clients geleitet, wodurch die Latenz beim Abrufen reduziert wird. Bei Ausfällen wird automatisch auf die anderen Knoten zurückgegriffen.

  • Vermeiden Sie teure Befehle – Vermeiden Sie die Ausführung rechen- und E/A-intensiver Operationen, wie z. B. die Befehle KEYS und SMEMBERS. Wir empfehlen diesen Ansatz, da diese Operationen die Last auf dem Cluster erhöhen und Einfluss auf die Performance des Clusters haben. Verwenden Sie stattdessen die Befehle SCAN und SSCAN.

  • Befolgen Sie die bewährten Methoden von Lua – Vermeiden Sie lange laufende Lua-Skripte und deklarieren Sie Schlüssel, die in Lua-Skripten verwendet werden, immer im Voraus. Wir empfehlen diesen Ansatz, um festzustellen, dass im Lua-Skript keine slotübergreifenden Befehle verwendet werden. Vergewissern Sie sich, dass die in Lua-Skripts verwendeten Schlüssel zum gleichen Slot gehören.

  • Sharded Pub/Sub verwenden — Wenn Sie Valkey oder Redis OSS zur Unterstützung von Pub/Sub-Workloads mit hohem Durchsatz verwenden, empfehlen wir die Verwendung von Sharded Pub/Sub (verfügbar mit Valkey und mit Redis 7 oder höher). OSS Herkömmliche Pub/Sub-Cluster mit aktiviertem Cluster-Modus senden Nachrichten an alle Knoten im Cluster, was zu hoher EngineCPUUtilization führen kann. Beachten Sie, dass bei serverlosen, herkömmlichen Pub/Sub-Befehlen intern Sharded Pub/Sub-Befehle verwendet werden. ElastiCache

Themen