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 Schritte zur Fehlerbehebung und bewährte Methoden mit ElastiCache
Die folgenden Themen enthalten Hinweise zur Fehlerbehebung bei Fehlern und Problemen, die bei der Verwendung auftreten können. ElastiCache Wenn Sie ein Problem finden, das hier nicht aufgeführt ist, können Sie es über die Feedback-Schaltfläche auf dieser Seite melden.
Weitere Tipps zur Fehlerbehebung und Antworten auf häufig gestellte Supportfragen finden Sie im AWS Knowledge Center
Themen
Verbindungsprobleme
Wenn Sie keine Verbindung zu Ihrem ElastiCache Cache herstellen können, ziehen Sie eine der folgenden Möglichkeiten in Betracht:
VerwendungTLS: Wenn beim Versuch, eine Verbindung zu Ihrem ElastiCache Endpunkt herzustellen, ein Verbindungsproblem auftritt, verwenden Sie es möglicherweise nicht TLS in Ihrem Client. Wenn Sie ElastiCache Serverless verwenden, ist die Verschlüsselung bei der Übertragung immer aktiviert. Stellen Sie sicher, dass Ihr Client TLS die Verbindung zum Cache verwendet. Erfahren Sie mehr über das Herstellen einer Verbindung zu einem TLS aktivierten Cache.
VPC: Auf ElastiCache Caches kann nur von einem VPC aus zugegriffen werden. Stellen Sie sicher, dass die EC2 Instanz, von der aus Sie auf den Cache zugreifen, und der ElastiCache Cache in derselben VPC Instanz erstellt wurden. Alternativ müssen Sie das VPCPeering zwischen dem Ort aktivieren, VPC an dem sich Ihre EC2 Instance befindet, und dem VPC Ort, an dem Sie Ihren Cache erstellen.
Sicherheitsgruppen: ElastiCache verwendet Sicherheitsgruppen, um den Zugriff auf Ihren Cache zu kontrollieren. Berücksichtigen Sie dabei Folgendes:
Stellen Sie sicher, dass die von Ihrem ElastiCache Cache verwendete Sicherheitsgruppe eingehenden Zugriff von Ihrer EC2 Instance aus darauf zulässt. Hier erfahren Sie, wie Sie Regeln für eingehenden Datenverkehr in Ihrer Sicherheitsgruppe korrekt einrichten.
Stellen Sie sicher, dass die von Ihrem ElastiCache Cache verwendete Sicherheitsgruppe den Zugriff auf die Ports Ihres Caches ermöglicht (6379 und 6380 für serverlose Verbindungen und standardmäßig 6379 für selbst entworfene Ports). ElastiCache verwendet diese Ports, um Valkey- oder Redis-Befehle zu akzeptieren. OSS Erfahren Sie hier mehr darüber, wie Sie den Portzugriff einrichten.
Wenn die Verbindung weiterhin schwierig ist, finden Sie Anhaltende Verbindungsprobleme weitere Schritte.
Valkey- oder Redis-Client-Fehler OSS
ElastiCache Auf Serverless kann nur über Clients zugegriffen werden, die das Valkey- oder OSS Redis-Clustermodus-Protokoll unterstützen. Auf selbst entworfene Cluster kann von Clients in beiden Modi zugegriffen werden, abhängig von der Clusterkonfiguration.
Wenn bei Ihrem Client Fehler auftreten, sollten Sie Folgendes beachten:
Clustermodus: Wenn bei dem SELECT
Befehl CROSSLOT Fehler oder Fehler auftreten, versuchen Sie möglicherweise, mit einem Valkey- oder OSS Redis-Client, der das Cluster-Protokoll nicht unterstützt, auf einen Cache mit aktiviertem Clustermodus zuzugreifen. ElastiCache Serverless unterstützt nur Clients, die das Valkey- oder Redis-Clusterprotokoll unterstützen. OSS Wenn Sie Valkey oder Redis OSS im „Cluster-Modus deaktiviert“ (CMD) verwenden möchten, müssen Sie Ihren eigenen Cluster entwerfen. CROSSLOTFehler: Wenn der
ERR CROSSLOT Keys in request don't hash to the same slotFehler auftritt, versuchen Sie möglicherweise, auf Schlüssel zuzugreifen, die nicht zu demselben Steckplatz in einem Clustermodus-Cache gehören. Zur Erinnerung: ElastiCache Serverless arbeitet immer im Clustermodus. Operationen mit mehreren Schlüsseln, Transaktionen oder Lua-Skripten mit mehreren Schlüsseln sind nur zulässig, wenn sich alle beteiligten Schlüssel im selben Hash-Slot befinden.
Fehlerbehebung bei hoher Latenz in Serverless ElastiCache
Wenn bei Ihrem Workload eine hohe Latenz auftritt, können Sie anhand der SuccessfulWriteRequestLatency Messwerte CloudWatch SuccessfulReadRequestLatency und überprüfen, ob die Latenz mit ElastiCache Serverless zusammenhängt. Diese Metriken messen die Latenz, die innerhalb von ElastiCache Serverless liegt. Die clientseitige Latenz und die Netzwerkausfallzeiten zwischen Ihrem Client und dem ElastiCache serverlosen Endpunkt sind nicht enthalten.
Fehlerbehebung bei der clientseitigen Latenz
Wenn Sie eine erhöhte Latenz auf der Clientseite, aber keinen entsprechenden Anstieg CloudWatch SuccessfulReadRequestLatency der SuccessfulWriteRequestLatency Messwerte für die serverseitige Latenz feststellen, sollten Sie Folgendes beachten:
Stellen Sie sicher, dass die Sicherheitsgruppe den Zugriff auf die Ports 6379 und 6380 zulässt: ElastiCache Serverless verwendet den 6379-Port für den primären Endpunkt und den 6380-Port für den Leser-Endpunkt. Einige Clients stellen für jede neue Verbindung eine Verbindung zu beiden Ports her, auch wenn Ihre Anwendung die Funktion „Aus Replikat lesen“ nicht verwendet. Wenn Ihre Sicherheitsgruppe keinen eingehenden Zugriff auf beide Ports zulässt, kann der Verbindungsaufbau länger dauern. Erfahren Sie hier mehr darüber, wie Sie den Portzugriff einrichten.
Fehlerbehebung bei serverseitiger Latenz
Einige Schwankungen und gelegentliche Spitzenwerte sollten keinen Anlass zur Sorge geben. Wenn die Average Statistik jedoch einen starken Anstieg zeigt und anhält, sollten Sie im AWS Health Dashboard und in Ihrem Personal Health Dashboard nach weiteren Informationen suchen. Falls erforderlich, erwägen Sie, einen Support-Fall mit zu eröffnen. AWS Support
Ziehen Sie die folgenden bewährten Methoden und Strategien zur Reduzierung der Latenz in Betracht:
Read from Replica aktivieren: Wenn Ihre Anwendung dies zulässt, empfehlen wir, die Funktion „Read from Replica“ in Ihrem Valkey- oder OSS Redis-Client zu aktivieren, um Lesevorgänge zu skalieren und eine geringere Latenz zu erreichen. Wenn diese Option aktiviert ist, versucht ElastiCache Serverless, Ihre Leseanfragen an Replikat-Cache-Knoten weiterzuleiten, die sich in derselben Availability Zone (AZ) wie Ihr Client befinden, wodurch AZ-übergreifende Netzwerklatenzen vermieden werden. Beachten Sie, dass die Aktivierung der Funktion „Aus Replikat lesen“ in Ihrem Client bedeutet, dass Ihre Anwendung eine eventuelle Datenkonsistenz akzeptiert. Ihre Anwendung empfängt möglicherweise für einige Zeit ältere Daten, wenn Sie versuchen, sie zu lesen, nachdem Sie in einen Schlüssel geschrieben haben.
Stellen Sie sicher, dass Ihre Anwendung im selben AZs Cache bereitgestellt wird: Möglicherweise stellen Sie eine höhere clientseitige Latenz fest, wenn Ihre Anwendung nicht im selben AZs Cache bereitgestellt wird. Wenn Sie einen serverlosen Cache erstellen, können Sie die Subnetze angeben, von denen aus Ihre Anwendung auf den Cache zugreift, und ElastiCache Serverless erstellt VPC Endpoints in diesen Subnetzen. Stellen Sie sicher, dass Ihre Anwendung in derselben Umgebung bereitgestellt wird. AZs Andernfalls kann es bei Ihrer Anwendung beim Zugriff auf den Cache zu einem AZ-übergreifenden Hop kommen, was zu einer höheren clientseitigen Latenz führt.
Verbindungen wiederverwenden: ElastiCache Serverlose Anfragen werden über eine TLS aktivierte TCP Verbindung mithilfe des Protokolls gestellt. RESP Das Initiieren der Verbindung (einschließlich der Authentifizierung der Verbindung, falls konfiguriert) nimmt Zeit in Anspruch, sodass die Latenz der ersten Anfrage höher als üblich ist. Anfragen über eine bereits initialisierte Verbindung sorgen für eine gleichbleibend niedrige ElastiCache Latenz. Aus diesem Grund sollten Sie die Verwendung von Verbindungspooling oder die Wiederverwendung vorhandener Valkey- oder Redis-Verbindungen in Betracht ziehen. OSS
Skalierungsgeschwindigkeit: ElastiCache Serverless skaliert automatisch, wenn Ihre Anforderungsrate steigt. Ein plötzlicher starker Anstieg der Anforderungsrate, der schneller ist als die Geschwindigkeit, mit der ElastiCache Serverless skaliert, kann für einige Zeit zu einer erhöhten Latenz führen. ElastiCache Serverless kann die unterstützte Anforderungsrate in der Regel schnell erhöhen. Es dauert bis zu 10 bis 12 Minuten, bis sich die Anforderungsrate verdoppelt.
Untersuchen Sie Befehle mit langer Laufzeit: Einige Valkey- oder OSS Redis-Befehle, einschließlich Lua-Skripten oder Befehle für große Datenstrukturen, können lange laufen. ElastiCache Veröffentlicht Metriken auf Befehlsebene, um diese Befehle zu identifizieren. Mit ElastiCache Serverless können Sie die
BasedECPUsMetriken verwenden.Gedrosselte Anfragen: Wenn Anfragen in ElastiCache Serverless gedrosselt werden, kann es zu einem Anstieg der clientseitigen Latenz in Ihrer Anwendung kommen. Wenn Anfragen in Serverless gedrosselt werden, sollten Sie einen ElastiCache Anstieg der Serverless-Metrik feststellen. ThrottledRequests ElastiCache Im folgenden Abschnitt finden Sie Informationen zur Behebung gedrosselter Anfragen.
Gleichmäßige Verteilung von Schlüsseln und Anfragen: ElastiCache Bei Valkey und Redis OSS kann eine ungleichmäßige Verteilung von Schlüsseln oder Anfragen pro Steckplatz zu einem Hot-Slot führen, was zu einer erhöhten Latenz führen kann. ElastiCache Serverless unterstützt bis zu 30.000 ECPUs /Sekunde (90.000 ECPUs /Sekunde bei Verwendung von Read from Replica) auf einem einzigen Steckplatz in einer Arbeitslast, die einfache /-Befehle ausführt. SET GET Wir empfehlen, Ihre Schlüssel- und Anforderungsverteilung auf die einzelnen Slots zu überprüfen und für eine gleichmäßige Verteilung zu sorgen, falls Ihre Anforderungsrate diese Grenze überschreitet.
Behebung von Drosselungsproblemen in Serverless ElastiCache
In serviceorientierten Architekturen und verteilten Systemen wird die Begrenzung der Geschwindigkeit, mit der API Anrufe von verschiedenen Servicekomponenten verarbeitet werden, als Drosselung bezeichnet. Dadurch werden Spannungsspitzen ausgeglichen, Diskrepanzen im Komponentendurchsatz kontrolliert und bei unerwarteten Betriebsereignissen besser vorhersehbare Wiederherstellungen ermöglicht. ElastiCache Serverless ist für diese Art von Architekturen konzipiert, und die meisten Valkey- oder Redis-Clients verfügen über integrierte OSS Wiederholungsversuche für gedrosselte Anfragen. Ein gewisses Maß an Drosselung ist nicht zwangsläufig ein Problem für Ihre Anwendung. Eine anhaltende Drosselung eines latenzsensitiven Teils des Datenworkflows kann sich jedoch negativ auf die Benutzererfahrung auswirken und die allgemeine Effizienz des Systems beeinträchtigen.
Wenn Anfragen in Serverless gedrosselt werden, sollten Sie einen Anstieg der ElastiCache Serverless-Metrik feststellen. ThrottledRequests ElastiCache Wenn Sie eine hohe Anzahl gedrosselter Anfragen feststellen, sollten Sie Folgendes beachten:
Skalierungsgeschwindigkeit: ElastiCache Serverless wird automatisch skaliert, wenn Sie mehr Daten aufnehmen oder Ihre Anforderungsrate erhöhen. Wenn Ihre Anwendung schneller skaliert als die Geschwindigkeit, mit der Serverless skaliert, werden Ihre Anfragen möglicherweise gedrosselt, während ElastiCache Serverless an Ihre Arbeitslast angepasst wird. ElastiCache ElastiCache Serverless kann die Speichergröße in der Regel schnell erhöhen. Es dauert bis zu 10 bis 12 Minuten, bis sich die Speichergröße in Ihrem Cache verdoppelt hat.
Gleichmäßige Verteilung von Schlüsseln und Anfragen: ElastiCache Bei Valkey oder Redis OSS kann eine ungleichmäßige Verteilung von Schlüsseln oder Anfragen pro Steckplatz zu einem Hot-Slot führen. Ein Hot-Slot kann zu einer Drosselung von Anfragen führen, wenn die Anforderungsrate für einen einzelnen Slot 30.000 ECPUs /Sekunde übersteigt, bei einer Arbeitslast, die einfache /-Befehle ausführt. SET GET
Aus Replikat lesen: Wenn Ihre Anwendung dies zulässt, sollten Sie in Erwägung ziehen, die Funktion „Aus Replikat lesen“ zu verwenden. Die meisten Valkey- oder OSS Redis-Clients können so konfiguriert werden, dass sie Lesevorgänge“ skalieren „, sodass Lesevorgänge direkt an Replikatknoten weitergeleitet werden. Mit dieser Funktion können Sie den Lesetraffic skalieren. Darüber hinaus leitet ElastiCache Serverless automatisch Lesevorgänge von Replikatanfragen an Knoten weiter, die sich in derselben Availability Zone wie Ihre Anwendung befinden, was zu einer geringeren Latenz führt. Wenn Read from Replica aktiviert ist, können Sie bei Workloads mit einfachen /-Befehlen bis zu 90.000 ECPUs /Sekunde an einem einzigen Steckplatz erreichen. SET GET
Verwandte Themen
