Meilleures pratiques de Redis OSS - Amazon ElastiCache (Redis OSS)

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.

Meilleures pratiques de Redis OSS

Voici les meilleures pratiques relatives à l'utilisation de Redis OSS pour améliorer les performances et la fiabilité :

  • 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 longue durée : la création d’une connexion est coûteuse et nécessite du temps et des ressources de CPU 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 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 Redis OSS 7 ou version ultérieure). 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.