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.
Bewährte Methoden für die Verwendung von Read Replicas
Viele Anwendungen, wie Sitzungsspeicher, Bestenlisten und Empfehlungsmodule, erfordern eine hohe Verfügbarkeit und verarbeiten deutlich mehr Lese- als Schreibvorgänge. Diese Anwendungen können häufig leicht veraltete Daten tolerieren (letztendliche Konsistenz), was bedeutet, dass es akzeptabel ist, wenn verschiedene Benutzer vorübergehend leicht unterschiedliche Versionen derselben Daten sehen. Zum Beispiel:
Im Cache gespeicherte Abfrageergebnisse können häufig leicht veraltete Daten tolerieren, insbesondere bei zwischengespeicherten Mustern, bei denen die Quelle der Wahrheit extern ist.
In einer Gaming-Bestenliste wirkt sich eine Verzögerung von einigen Sekunden bei aktualisierten Ergebnissen häufig nicht wesentlich auf die Benutzererfahrung aus.
Bei Sitzungsspeichern wirken sich geringfügige Verzögerungen bei der Übertragung von Sitzungsdaten zwischen Replikaten selten auf die Anwendungsfunktionalität aus.
Empfehlungs-Engines verwenden in der Regel historische Datenanalysen, sodass Konsistenz in Echtzeit weniger wichtig ist.
Letztendliche Konsistenz bedeutet, dass alle Replikatknoten irgendwann dieselben Daten zurückgeben, sobald der Replikationsprozess abgeschlossen ist, normalerweise innerhalb von Millisekunden. Für solche Anwendungsfälle ist die Implementierung von Read Replicas eine effektive Strategie, um die Latenz beim Lesen aus Ihrer Instance zu reduzieren. ElastiCache
Die Verwendung von Read Replicas in Amazon ElastiCache kann erhebliche Leistungsvorteile bieten durch:
Verbesserte Leseskalierbarkeit
Verteilt Lesevorgänge auf mehrere Replikatknoten
Lädt den Lesetraffic vom primären Knoten ab
Reduziert die Leselatenz, indem Anfragen von geografisch näher gelegenen Replikaten bearbeitet werden
Optimierte Leistung des Primärknotens
Weist Ressourcen des primären Knotens für Schreiboperationen zu
Reduziert den Verbindungsaufwand auf dem Primärknoten
Verbessert die Schreibleistung und sorgt für bessere Antwortzeiten in Zeiten mit hohem Datenverkehr
Verwenden von Read from Replica in Serverless ElastiCache
ElastiCache Serverless bietet zwei verschiedene Endpunkte für unterschiedliche Konsistenzanforderungen. Die beiden Endpunkte verwenden denselben DNS-Namen, aber unterschiedliche Ports. Um den read-from-replica Port verwenden zu können, müssen Sie den Zugriff auf beide Ports von Ihrer Client-Anwendung aus autorisieren, indem Sie die Sicherheitsgruppen und Netzwerkzugriffskontrolllisten Ihrer VPC konfigurieren.
Primärer Endpunkt (Port 6379)
Wird für Operationen verwendet, die sofortige Konsistenz erfordern
Garantiert das Lesen der meisten up-to-date Daten
Am besten für kritische Transaktionen und Schreibvorgänge
Erforderlich für Schreiboperationen
Beispiel:
test-12345.serverless.use1.cache.amazonaws.com:6379
Latenzoptimierter Endpunkt (Port 6380)
Optimiert für Lesevorgänge, die eine eventuelle Konsistenz tolerieren
Wenn möglich, leitet ElastiCache Serverless Leseanfragen automatisch an den Replikatknoten in der lokalen Availability Zone des Clients weiter. Diese Optimierung sorgt für eine geringere Latenz, da die zusätzliche Netzwerklatenz vermieden wird, die beim Abrufen von Daten von einem Knoten in einer anderen Availability Zone entsteht.
ElastiCache Serverless wählt automatisch verfügbare Knoten in anderen Zonen aus, wenn ein lokaler Knoten nicht verfügbar ist
Beispiel:
test-12345.serverless.use1.cache.amazonaws.com:6380
Clients wie Glide und Lettuce erkennen Lesevorgänge automatisch und leiten sie an den latenzoptimierten Endpunkt weiter, wenn Sie die Konfiguration „Read from Replica“ angeben. Wenn Ihr Client die Routing-Konfiguration nicht unterstützt (z. B. Valkey-Java und ältere Jedis-Versionen), müssen Sie den richtigen Port und die richtige Client-Konfiguration definieren, um aus Replikaten zu lesen.
Verbindung herstellen, um Repliken in Serverless zu lesen — Valkey und Glide ElastiCache
Der folgende Codeausschnitt zeigt, wie Sie Read from Replica für ElastiCache Serverless in der Valkey-Glide-Bibliothek konfigurieren können. Sie müssen keinen Port für das Lesen von Replikaten angeben, aber Sie müssen die Routing-Konfiguration konfigurieren. ReadFrom.PREFER_REPLICA
package glide.examples; import glide.api.GlideClusterClient; import glide.api.logging.Logger; import glide.api.models.configuration.GlideClusterClientConfiguration; import glide.api.models.configuration.NodeAddress; import glide.api.models.exceptions.ClosingException; import glide.api.models.exceptions.ConnectionException; import glide.api.models.exceptions.TimeoutException; import glide.api.models.configuration.ReadFrom; import java.util.concurrent.CompletableFuture; import java.util.concurrent.ExecutionException; public class ClusterExample { public static void main(String[] args) { // Set logger configuration Logger.setLoggerConfig(Logger.Level.INFO); GlideClusterClient client = null; try { System.out.println("Connecting to Valkey Glide..."); // Configure the Glide Client GlideClusterClientConfiguration config = GlideClusterClientConfiguration.builder() .address(NodeAddress.builder() .host("your-endpoint") .port(6379) .build()) .useTLS(true) .readFrom(ReadFrom.PREFER_REPLICA) .build(); // Create the GlideClusterClient client = GlideClusterClient.createClient(config).get(); System.out.println("Connected successfully."); // Perform SET operation CompletableFuture<String> setResponse = client.set("key", "value"); System.out.println("Set key 'key' to 'value': " + setResponse.get()); // Perform GET operation CompletableFuture<String> getResponse = client.get("key"); System.out.println("Get response for 'key': " + getResponse.get()); // Perform PING operation CompletableFuture<String> pingResponse = client.ping(); System.out.println("PING response: " + pingResponse.get()); } catch (ClosingException | ConnectionException | TimeoutException | ExecutionException e) { System.err.println("An exception occurred: "); e.printStackTrace(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { // Close the client connection if (client != null) { try { client.close(); System.out.println("Client connection closed."); } catch (ClosingException | ExecutionException e) { System.err.println("Error closing client: " + e.getMessage()); } } } } }