Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Bonnes pratiques d'utilisation des répliques de lecture
De nombreuses applications, telles que les magasins de sessions, les classements et les moteurs de recommandation, nécessitent une haute disponibilité et gèrent beaucoup plus d'opérations de lecture que d'opérations d'écriture. Ces applications peuvent souvent tolérer des données légèrement périmées (cohérence éventuelle), ce qui signifie qu'il est acceptable que différents utilisateurs voient momentanément des versions légèrement différentes des mêmes données. Par exemple :
Les résultats des requêtes mis en cache peuvent souvent tolérer des données légèrement périmées, en particulier pour les modèles mis en cache où la source de vérité est externe.
Dans un classement de jeu, un retard de quelques secondes dans la mise à jour des scores n'a souvent pas d'impact significatif sur l'expérience utilisateur.
En ce qui concerne les stockages de sessions, certains légers retards dans la propagation des données de session entre les répliques affectent rarement les fonctionnalités de l'application.
Les moteurs de recommandation utilisent généralement l'analyse des données historiques, de sorte que la cohérence en temps réel est moins critique.
La cohérence éventuelle signifie que tous les nœuds de réplication renverront les mêmes données une fois le processus de réplication terminé, généralement en quelques millisecondes. Dans de tels cas d'utilisation, la mise en œuvre de répliques de lecture constitue une stratégie efficace pour réduire le temps de latence lors de la lecture depuis votre ElastiCache instance.
L'utilisation de répliques de lecture dans Amazon ElastiCache peut apporter des avantages significatifs en termes de performances grâce à :
Évolutivité de lecture améliorée
Répartit les opérations de lecture sur plusieurs nœuds de réplication
Décharge le trafic de lecture du nœud principal
Réduit la latence de lecture en répondant aux demandes provenant de répliques géographiquement plus proches
Performances optimisées du nœud principal
Dédie les ressources du nœud principal aux opérations d'écriture
Réduit les frais de connexion sur le nœud principal
Améliore les performances d'écriture et maintient de meilleurs temps de réponse pendant les périodes de pointe
Utilisation de Read from Replica en mode ElastiCache Serverless
ElastiCache serverless fournit deux points de terminaison différents, pour des exigences de cohérence différentes. Les deux points de terminaison utilisent le même nom DNS mais des ports différents. Pour utiliser le read-from-replica port, vous devez autoriser l'accès aux deux ports depuis votre application cliente en configurant les groupes de sécurité et les listes de contrôle d'accès réseau de votre VPC.
Point de terminaison principal (port 6379)
Utilisation pour les opérations nécessitant une cohérence immédiate
Garantit la lecture du plus grand nombre up-to-date de données
Idéal pour les transactions critiques et les opérations d'écriture
Nécessaire pour les opérations d'écriture
Exemple :
test-12345.serverless.use1.cache.amazonaws.com:6379
Point de terminaison optimisé pour la latence (port 6380)
Optimisé pour les opérations de lecture qui peuvent tolérer une éventuelle cohérence
Lorsque cela est possible, le mode ElastiCache sans serveur achemine automatiquement les demandes de lecture vers le nœud de réplication dans la zone de disponibilité locale du client. Cette optimisation permet de réduire la latence en évitant la latence réseau supplémentaire encourue lors de la récupération de données à partir d'un nœud situé dans une autre zone de disponibilité.
ElastiCache serverless sélectionne automatiquement les nœuds disponibles dans d'autres zones si un nœud local n'est pas disponible
Exemple :
test-12345.serverless.use1.cache.amazonaws.com:6380
Les clients tels que Glide et Lettuce détectent et acheminent automatiquement les lectures vers le point de terminaison optimisé pour la latence si vous fournissez la configuration de lecture depuis une réplique. Si votre client ne prend pas en charge la configuration du routage (par exemple, Valkey-Java et les anciennes versions de Jedis), vous devez définir le port et la configuration client appropriés pour lire les répliques.
Connexion pour lire des répliques en mode ElastiCache Serverless - Valkey and Glide
L'extrait de code suivant montre comment configurer la lecture depuis une réplique pour ElastiCache Serverless dans la bibliothèque Valkey Glide. Il n'est pas nécessaire de spécifier le port pour la lecture à partir des répliques, mais vous devez configurer la configuration ReadFrom.PREFER_REPLICA
du routage.
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()); } } } } }