View a markdown version of this page

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

  • Konfigurationen mit aktiviertem Clustermodus verwenden — Mit dieser Option kann der Cache horizontal skaliert Cluster-mode 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.

  • 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 (knotenbasierte Cluster) bereitgestellt haben, leiten Sie Lesevorgänge direkt an Replikate weiter, um eine bessere Skalierbarkeit und geringere Latenz zu erreichen. and/or Lesevorgänge aus Replikaten sind mit dem Primärknoten letztendlich konsistent.

    Vermeiden Sie es in einem knotenbasierten 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 Lesevorgänge, wenn vom Replikat-Port (6380) gelesen wird, 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 es, I/O rechenintensive Operationen wie die Befehle und auszuführen. KEYS 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 verwenden pub/sub — Wenn Sie Valkey oder Redis OSS verwenden, um pub/sub Workloads mit hohem Durchsatz zu unterstützen, empfehlen wir die Verwendung von Sharded pub/sub (verfügbar mit Valkey und mit Redis OSS 7 oder höher). Herkömmliche Cluster, die pub/sub im Clustermodus aktiviert sind, senden Nachrichten an alle Knoten im Cluster, was zu hohen Werten führen kann. EngineCPUUtilization Beachten Sie, dass bei ElastiCache serverlosen Befehlen bei herkömmlichen pub/sub Befehlen intern Sharded-Befehle verwendet werden. pub/sub

Themen