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 OSS-Schnittstellen Valkey, Memcached und Redis. ElastiCache

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

  • Langlebige Verbindungen verwenden – 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) 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 OSS 7 oder höher). Herkömmliche Pub/Sub-Cluster mit aktiviertem Cluster-Modus senden Nachrichten an alle Knoten im Cluster, was zu hoher EngineCPUUtilization führen kann. Beachten ElastiCache Sie pub/sub commands internally use sharded pub/sub das bei serverlosen, herkömmlichen Befehlen.

Themen