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.
Ausnahmebehandlung und Wiederholungen
Das Erstellen robuster Anwendungen auf Neptune bedeutet oft, sich auf das Unerwartete vorzubereiten, insbesondere wenn es um die Behandlung von Fehlern geht, die von der Datenbank zurückgegeben werden. Eine der häufigsten Reaktionen auf serverseitige Ausnahmen besteht darin, den fehlgeschlagenen Vorgang erneut zu versuchen. Die Logik der Wiederholungsversuche ist zwar für robuste Systeme unerlässlich, Sie müssen sich jedoch darüber im Klaren sein, dass nicht alle Fehler auf die gleiche Weise behandelt werden sollten. Anstatt sich auf generisches Wiederholungsverhalten zu verlassen, kann ein durchdachter Ansatz Ihnen helfen, zuverlässigere und effizientere Anwendungen zu entwickeln.
Warum Wiederholungslogik wichtig ist
Die Wiederholungslogik ist eine wichtige Komponente jeder verteilten Anwendung. Vorübergehende Probleme wie Netzwerkinstabilität, vorübergehende Ressourcenbeschränkungen oder gleichzeitige Änderungskonflikte können zum Fehlschlagen von Vorgängen führen. In vielen Fällen deuten diese Fehler nicht auf ein dauerhaftes Problem hin und können behoben werden, indem Sie warten und es erneut versuchen. Die Implementierung einer soliden Wiederholungsstrategie berücksichtigt die Realität unvollkommener Umgebungen in verteilten Systemen und gewährleistet so eine höhere Zuverlässigkeit und Kontinuität, ohne dass manuelle Eingriffe erforderlich sind.
Die Risiken wahlloser Wiederholungsversuche
Wenn Sie standardmäßig jeden Fehler erneut versuchen, kann dies mehrere unbeabsichtigte Folgen haben:
-
Zunehmende Konflikte — Wenn Operationen, die aufgrund hoher Parallelität fehlschlagen, wiederholt wiederholt werden, kann sich der Konflikt insgesamt verschärfen. Dies kann zu einem Zyklus fehlgeschlagener Transaktionen und einer verminderten Leistung führen.
-
Erschöpfung der Ressourcen — Wahllose Wiederholungsversuche können zusätzliche Systemressourcen verbrauchen, sowohl auf der Client- als auch auf der Serverseite. Dies kann möglicherweise zu einer Drosselung oder sogar zu einer Verschlechterung des Dienstes führen.
-
Höhere Latenz für Clients — Übermäßige Wiederholungsversuche können zu erheblichen Verzögerungen bei Client-Anwendungen führen, insbesondere wenn jede Wiederholung Wartezeiten mit sich bringt. Dies kann sich negativ auf die Benutzererfahrung und nachgelagerte Prozesse auswirken.
Entwicklung einer praktischen Wiederholungsstrategie
Um eine robuste und effiziente Anwendung zu erstellen, entwickeln Sie eine Wiederholungsstrategie, die auf die spezifischen Fehlerbedingungen zugeschnitten ist, auf die Ihre Anwendung stoßen könnte. Hier sind einige Überlegungen, die Sie bei Ihrem Ansatz berücksichtigen sollten:
-
Identifizieren Sie Fehler, die wiederholt werden können — Nicht alle Ausnahmen sollten erneut versucht werden. Beispielsweise sollten Syntaxfehler, Authentifizierungsfehler oder ungültige Abfragen keinen erneuten Versuch auslösen. Neptune stellt Fehlercodes und allgemeine Empfehlungen zur Verfügung, bei denen Fehler gefahrlos wiederholt werden können. Sie müssen jedoch die Logik implementieren, die zu Ihrem Anwendungsfall passt.
-
Implementieren Sie exponentielles Backoff — Verwenden Sie bei vorübergehenden Fehlern eine exponentielle Backoff-Strategie, um die Wartezeit zwischen den Wiederholungen schrittweise zu verlängern. Dies hilft, Konflikte zu vermeiden und reduziert das Risiko kaskadierender Ausfälle.
-
Beachten Sie die anfängliche Pausenlänge — Eine zu schnelle Ausführung des ersten Wiederholungsversuchs kann mit demselben Fehler enden, wenn dem Server nicht genügend Zeit eingeräumt wurde, um Ressourcen freizugeben, die für eine erfolgreiche Abfrage erforderlich sind. Eine längere Pause in den richtigen Situationen könnte verschwendete Anfragen und den Serverdruck reduzieren.
-
Hinzufügen von Jitter zum Backoff — Obwohl exponentielles Backoff effektiv ist, kann es dennoch zu synchronisierten Wiederholungsstürmen führen, wenn viele Clients gleichzeitig ausfallen und es dann gemeinsam erneut versuchen. Das Hinzufügen von Jitter, einer kleinen zufälligen Variation der Backoff-Verzögerung, trägt dazu bei, Wiederholungsversuche zu verteilen, wodurch die Wahrscheinlichkeit verringert wird, dass alle Clients gleichzeitig versuchen, es erneut zu versuchen, was zu einer weiteren Lastspitze führt.
-
Wiederholungsversuche einschränken — Legen Sie eine angemessene Höchstzahl von Wiederholungsversuchen fest, um Endlosschleifen und Ressourcenauslastung zu vermeiden.
-
Überwachen und anpassen — Überwachen Sie kontinuierlich die Fehlerrate Ihrer Anwendung und passen Sie Ihre Wiederholungsstrategie nach Bedarf an. Wenn Sie eine hohe Anzahl von Wiederholungsversuchen für einen bestimmten Vorgang feststellen, überlegen Sie, ob der Vorgang optimiert oder serialisiert werden kann.
Eine eingehendere Erläuterung von exponentiellem Backoff und Jitter als allgemeines Cloud-Entwurfsmuster finden Sie im Abschnitt Erneut versuchen mit Backkoff in Prescriptive Guidance. AWS
Beispielszenarien
Die richtige Wiederholungsstrategie hängt von der Art des Fehlers, der Arbeitslast und den beobachteten Fehlermustern ab. In der folgenden Tabelle werden einige gängige Fehlerszenarien zusammengefasst und erläutert, wie sich die Überlegungen zur Wiederholungsstrategie auf die einzelnen Szenarien beziehen. Es folgen erläuternde Absätze für zusätzlichen Kontext.
|
Szenario |
Wiederholbar? |
Backoff und Jitter |
Erste Pause |
Limit für Wiederholungsversuche |
Überwachen und anpassen |
|---|---|---|---|---|---|
|
Gelegentliche CME bei kurzen Anfragen |
Ja |
Kurzer Rückstand, füge Jitter hinzu |
Kurz (z. B. 100 ms) |
Hoch |
Achten Sie auf steigende CME-Raten |
|
Häufiges CME bei Anfragen Longer-Running |
Ja |
Längerer Backoff, füge Jitter hinzu |
Länger (z. B. 2 s) |
Mittel |
Untersuchen Sie Konflikte und reduzieren Sie sie |
|
Speicherbeschränkungen für teure Abfragen |
Ja |
Langer Rückstand |
Lang (z. B. 5-10 Sekunden) |
Niedrig |
Optimieren Sie die Abfrage, warnen Sie, wenn sie persistent ist |
|
Timeout bei moderaten Abfragen |
Vielleicht |
Mäßiger Backoff, füge Jitter hinzu |
Moderat (z. B. 1s) |
Gering bis Mäßig |
Beurteilen Sie die Serverlast und das Abfragedesign |
Szenario 1: Gelegentliche CME bei kurzen Abfragen
Bei einem Workload, der bei kurzen, einfachen Updates selten ConcurrentModificationException auftritt, sind diese Fehler in der Regel vorübergehend und können problemlos erneut versucht werden. Machen Sie vor dem ersten Wiederholungsversuch eine kurze Anfangspause (z. B. 100 Millisekunden). In dieser Zeit kann jede kurze Sperre aufgehoben werden. Kombinieren Sie dies mit einem kurzen exponentiellen Backoff und Jitter, um synchronisierte Wiederholungen zu vermeiden. Da die Kosten für Wiederholungen gering sind, ist ein höheres Wiederholungslimit angemessen. Überwachen Sie dennoch die CME-Rate, um jeden Trend zu zunehmenden Konflikten in Ihren Daten zu erkennen.
Szenario 2: Häufiges CME bei Abfragen mit langer Laufzeit
Wenn in Ihrer Anwendung bei Abfragen mit langer Laufzeit häufig CMEs auftreten, deutet dies auf schwerwiegendere Konflikte hin. Beginnen Sie in diesem Fall mit einer längeren Anfangspause (z. B. 2 Sekunden), um der aktuellen Abfrage, die die Sperre enthält, genügend Zeit zum Abschließen zu geben. Verwenden Sie einen längeren exponentiellen Backoff und fügen Sie Jitter hinzu. Begrenzen Sie die Anzahl der Wiederholungen, um übermäßige Verzögerungen und Ressourcenverbrauch zu vermeiden. Wenn der Konflikt weiterhin besteht, überprüfen Sie Ihre Arbeitslast auf Muster und erwägen Sie, Updates zu serialisieren oder die Parallelität zu reduzieren, um die eigentliche Ursache zu beheben.
Szenario 3: Speicherbeschränkungen für teure Abfragen
Wenn bei einer bekanntermaßen ressourcenintensiven Abfrage speicherbasierte Fehler auftreten, können Wiederholungsversuche sinnvoll sein, allerdings erst nach einer langen anfänglichen Pause (z. B. 5 bis 10 Sekunden oder länger), damit der Server Ressourcen freigeben kann. Verwenden Sie eine lange Backoff-Strategie und legen Sie ein niedriges Limit für Wiederholungsversuche fest, da es unwahrscheinlich ist, dass wiederholte Fehler ohne Änderungen an der Abfrage oder der Arbeitslast behoben werden. Dauerhafte Fehler sollten Warnmeldungen auslösen und eine Überprüfung der Abfragekomplexität und der Ressourcenauslastung veranlassen.
Szenario 4: Timeout bei moderaten Abfragen
Ein Timeout bei einer mäßig teuren Abfrage ist ein mehrdeutiger Fall. Manchmal kann ein erneuter Versuch erfolgreich sein, wenn der Timeout auf einen vorübergehenden Anstieg der Serverlast oder Netzwerkbedingungen zurückzuführen ist. Beginnen Sie mit einer moderaten Anfangspause (z. B. 1 Sekunde), damit sich das System erholen kann. Wenden Sie einen moderaten Backoff an und fügen Sie Jitter hinzu, um synchronisierte Wiederholungen zu vermeiden. Halten Sie das Limit für Wiederholungen niedrig bis moderat, da wiederholte Timeouts auf ein schwerwiegenderes Problem mit der Abfrage oder der Serverkapazität hinweisen können. Überwachen Sie auf Muster: Wenn es häufig zu Timeouts kommt, prüfen Sie, ob die Abfrage optimiert werden muss oder ob der Neptune-Cluster nicht ausreichend versorgt ist.
Überwachung und Beobachtbarkeit
Die Überwachung ist ein wichtiger Bestandteil jeder Wiederholungsstrategie. Eine effektive Beobachtbarkeit hilft Ihnen zu verstehen, wie gut Ihre Wiederholungslogik funktioniert, und gibt frühzeitig Hinweise, wenn etwas in Ihrer Workload- oder Cluster-Konfiguration Aufmerksamkeit erfordert.
MainRequestQueuePendingRequests
Diese CloudWatch Metrik verfolgt die Anzahl der Anfragen, die in der Eingabewarteschlange von Neptune warten. Ein steigender Wert zeigt an, dass Abfragen gesichert werden. Dies kann ein Zeichen für übermäßige Konflikte, unzureichend bereitgestellte Ressourcen oder Wiederholungsversuche sein. Wenn Sie diese Kennzahl überwachen, können Sie erkennen, wann Ihre Strategie für Wiederholungsversuche zu Problemen in der Warteschlange führt oder diese verschärft, und Sie können dazu veranlasst werden, Ihren Ansatz anzupassen, bevor Fehler eskalieren.
Andere Metriken CloudWatch
Andere Neptune-Metriken wie CPUUtilizationTotalRequestsPerSecond, und Abfragelatenz bieten zusätzlichen Kontext. Beispielsweise können eine hohe CPU-Auslastung in I/O Kombination mit wachsenden Warteschlangenlängen darauf hindeuten, dass Ihr Cluster überlastet ist oder dass Abfragen zu groß oder zu häufig sind. CloudWatch Für diese Metriken können Alarme eingerichtet werden, um Sie vor abnormalem Verhalten zu warnen und Ihnen dabei zu helfen, Spitzen bei Fehlern oder Wiederholungsversuchen mit den zugrunde liegenden Ressourcenbeschränkungen zu korrelieren.
Neptune-Status- und Abfrage-APIs
Die Neptune Status API für Gremlin und ihre analogen APIs für und SPARQL bieten eine Echtzeitansicht der auf dem Cluster akzeptierten OpenCypher und ausgeführten Abfragen. Dies ist nützlich, um Engpässe zu diagnostizieren oder die Auswirkungen der Wiederholungslogik in Echtzeit zu verstehen.
Durch die Kombination dieser Überwachungstools können Sie:
-
Erkennen Sie, wann Wiederholungsversuche zu Warteschlangen und Leistungseinbußen beitragen.
-
Identifizieren Sie, wann Sie Ihren Neptune-Cluster skalieren oder Abfragen optimieren sollten.
-
Stellen Sie sicher, dass Ihre Wiederholungsstrategie vorübergehende Fehler behebt, ohne tiefere Probleme zu maskieren.
-
Lassen Sie sich frühzeitig vor neu auftretenden Konflikten oder der Erschöpfung von Ressourcen warnen.
Proaktive Überwachung und Warnmeldungen sind für eine reibungslose Neptune-Bereitstellung unerlässlich, insbesondere wenn die Parallelität und Komplexität Ihrer Anwendung zunehmen.
