Bonnes pratiques générales - Amazon ElastiCache

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 générales

Vous trouverez ci-dessous des informations sur les meilleures pratiques d'utilisation des interfaces Valkey, Redis OSS et Memcached. ElastiCache

  • Utiliser des configurations activées en mode cluster : le mode cluster activé permet au cache de s'adapter horizontalement pour obtenir un stockage et un débit supérieurs à ceux d'une configuration désactivée en mode cluster. ElastiCache le mode serverless n'est disponible que dans une configuration activée en mode cluster.

  • Utilisez des connexions de longue durée : la création d'une nouvelle connexion est coûteuse et nécessite du temps et CPU des ressources provenant du cache. Réutilisez les connexions dans la mesure du possible (en regroupant les connexions, par exemple) pour amortir ce coût sur de nombreuses commandes.

  • Lecture à partir de répliques : si vous utilisez des répliques ElastiCache sans serveur ou si vous avez provisionné des répliques en lecture (clusters conçus par vos soins), effectuez des lectures directes vers des répliques pour obtenir une meilleure évolutivité et/ou une latence moindre. Les lectures de réplicas sont cohérentes avec le nœud primaire à terme.

    Dans un cluster auto-conçu, évitez de diriger les demandes de lecture vers un seul réplica en lecture, car les lectures risquent de ne pas être disponibles temporairement en cas de défaillance du nœud. Configurez votre client pour qu’il dirige les demandes de lecture vers au moins deux réplicas en lecture, ou qu’il dirige les lectures vers un seul réplica et le nœud primaire.

    En mode ElastiCache sans serveur, la lecture depuis le port de réplication (6380) dirige les lectures vers la zone de disponibilité locale du client lorsque cela est possible, réduisant ainsi la latence de récupération. Il retombera automatiquement sur les autres nœuds en cas de défaillance.

  • Évitez les commandes onéreuses – Évitez d'exécuter des opérations gourmandes en calcul et en I/O, telles que les commandes KEYS et SMEMBERS. Nous suggérons cette approche, car ces opérations augmentent la charge sur le cluster et ont un impact sur ses performances. Utilisez à la place les commandes SCAN et SSCAN.

  • Suivez les bonnes pratiques Lua – Évitez les longues exécutions de scripts Lua et déclarez toujours les clés utilisées dans les scripts Lua en amont. Nous recommandons cette approche pour déterminer que le script Lua n'utilise pas de commandes inter-emplacements. Veillez à ce que les clés utilisées dans les scripts Lua appartiennent au même emplacement.

  • Utiliser un pub/sub fragmenté — Lorsque vous utilisez Valkey ou Redis OSS pour prendre en charge des charges de travail pub/sub à haut débit, nous vous recommandons d'utiliser un pub/sub fragmenté (disponible avec Valkey et avec Redis 7 ou version ultérieure). OSS La fonctionnalité pub/sub traditionnelles dans les clusters en mode cluster activé diffuse des messages à tous les nœuds du cluster, ce qui peut entraîner une valeur EngineCPUUtilization élevée. Notez qu'en mode ElastiCache sans serveur, les commandes pub/sub traditionnelles utilisent en interne des commandes pub/sub fragmentées.

Rubriques