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.
Verwalten Sie Verbindungspools und den Lebenszyklus in containerisierten Umgebungen
Die effektive Verwaltung von Verbindungen zu Neptune ist in containerisierten Umgebungen, in denen Container (Pods in Kubernetes) häufig gestartet, gestoppt und skaliert werden, unerlässlich. Neptune erzwingt mehrere WebSocket Verbindungslimits:
Jeder Instanztyp hat eine maximale Anzahl gleichzeitiger Verbindungen WebSocket
Verbindungen im Leerlauf werden nach 20—25 Minuten Inaktivität geschlossen
Einige Treiber unterstützen regelmäßige Keep-Alive-Heartbeats, um Verbindungsabbrüche im Leerlauf zu verhindern. Beispielsweise keepAliveInterval sendet der Gremlin-Java-Treiber regelmäßig einen Ping an den Server. Ermitteln Sie anhand der Konfigurationsoptionen Ihres jeweiligen Treibers, welche Keep-Alive-Einstellungen verfügbar sind und wie sie mit dem Leerlauf-Timeout von Neptune interagieren.
Wenn Sie diese Grenzen kennen, können Sie die Verbindungsverwaltung so gestalten, dass sie gut mit Container-Orchestrierungsmustern wie rollierenden Bereitstellungen, Autoscaling und Container-Recycling funktioniert. Allgemeine Hinweise zur Verbindungsverwaltung mit dem Java-Gremlin-Treiber finden Sie unter und. Schließen des Clients zur Vermeidung des Verbindungs-Limits Erstellen einer neuen Verbindung nach einem Failover
Schließen Sie die Verbindungen beim Herunterfahren des Containers
Implementieren Sie ein ordnungsgemäßes Herunterfahren, indem Sie einen SIGTERM Handler hinzufügen, der Ihren Graph-Client schließt, bevor der Container beendet wird. Rufen Sie zum Beispiel Gremlin Javascluster.close(), Gremlins driverRemoteConnection.close() in Go oder Python oder Bolts driver.close() für den Neo4j-Treiber auf. Verwenden Sie in Kubernetes einen preStop Hook, um Verbindungen abzuleiten, bevor SIGTERM sie gesendet werden, insbesondere bei fortlaufenden Updates.
Anmerkung
Docker und Amazon ECS liefern nur SIGTERM an PID 1 im Container. Verwenden Sie das Exec-Formular in Ihrem Dockerfile (z. B. ENTRYPOINT ["java", "-jar", "app.jar"] nichtENTRYPOINT java -jar app.jar) oder einen Init-Prozess, tini um sicherzustellen, dass Ihre Anwendung das Signal empfängt.
Verwenden Sie eine einzelne Client-Instanz pro Container
Das Erstellen mehrerer Gremlin DriverRemoteConnection - oder neo4j.Driver Bolt-Instanzen im selben Container vervielfacht die Verbindungsnutzung. Teilen Sie eine einzelne Client-Instanz für alle Threads im Container. Die Client-Objekte sind threadsicher.
Größe der Verbindungspools im Verhältnis zu Ihrer Flotte
Stellen Sie maxConnectionPoolSize es so ein, dass die Gesamtzahl der Verbindungen in allen Containern das Verbindungslimit für Neptune-Instanzen nicht überschreitet. Wenn Sie beispielsweise 20 Container mit jeweils 8 Threads ausführen, berechnen Sie die Poolgröße pro Container so, dass das 20-fache der Poolgröße innerhalb des Instance-Limits für Ihren Instance-Typ bleibt. Weitere Informationen zur Konfiguration der Verbindungspoolgrößen finden Sie unterSetzen Sie maxInProcessPerConnection und maxSimultaneousUsagePerConnection auf den selben Wert..
Legen Sie ein Timeout für die Verbindungswartezeit fest
Stellen Sie im Java-Gremlin-Treiber einen angemessenen Wert einmaxWaitForConnection, z. B. 5—10 Sekunden. Die Standardeinstellung ist oft unendlich oder sehr lang, was dazu führt, dass Threads hängen bleiben, wenn der Pool erschöpft ist, und nicht schnell mit einem eindeutigen Fehler ausfallen. Nicht alle Sprachtreiber unterstützen diese Einstellung. Die entsprechende Konfigurationsoption finden Sie in der Dokumentation Ihres Treibers.
