Tair (Redis® OSS-Compatible):Séparation lecture/écriture

Pour les charges de travail à forte intensité de lectures, Tair (Redis OSS-compatible) vous permet d'activer ou de désactiver dynamiquement la séparation lecture/écriture. Cette fonctionnalité offre une solution hautement disponible et performante pour l'accès centralisé aux données fréquemment sollicitées et pour les lectures à forte concurrence. Dans une instance avec séparation lecture/écriture, un composant proxy développé par l'équipe Tair d'Alibaba Cloud identifie et achemine automatiquement les requêtes de lecture et d'écriture, tout en gérant les basculements. Cela simplifie l'intégration : inutile de modifier le code de votre application pour gérer le routage des requêtes ou les basculements.

Séparation lecture/écriture dans une architecture standard

Une instance avec séparation lecture/écriture utilisant une architecture standard se compose d'un nœud principal, d'un ou plusieurs réplicas en lecture, de serveurs proxy et d'un système de haute disponibilité. Les figures suivantes illustrent ces architectures.

Figure 1. Cloud-native

Figure 2. Classique (obsolète)

Remarques concernant les instances avec séparation lecture/écriture sur deux zones

Cloud-native (recommandé)

Classique (obsolète)

Les zones primaire et secondaire fournissent toutes deux des services. La configuration minimale est la suivante : Zone primaire : un nœud principal et un réplica en lecture. Zone secondaire : un réplica en lecture. Les zones primaire et secondaire disposent de points de terminaison distincts. Ces deux points de terminaison prennent en charge les opérations de lecture et d'écriture. Les requêtes de lecture provenant de la zone primaire sont acheminées uniquement vers le nœud principal ou les réplicas en lecture situés dans cette même zone. Les requêtes de lecture issues de la zone secondaire sont dirigées exclusivement vers les réplicas en lecture de cette zone. Cette architecture permet un accès basé sur la proximité géographique. Toutes les requêtes d'écriture sont routées vers le nœud principal de la zone primaire. La figure suivante illustre cette architecture. Remarque Nous vous recommandons de configurer au moins deux nœuds dans les zones primaire et secondaire : Zone primaire : un nœud principal et un réplica en lecture. Zone secondaire : deux réplicas en lecture.

La zone secondaire contient uniquement un nœud de réplication de secours à froid destiné à la sauvegarde des données ; elle ne traite aucun trafic. En cas de défaillance du nœud principal, les requêtes sont basculées vers le nœud de réplication.

Fonctionnalités

• Dynamique et facile à utiliser

  Vous pouvez activer la séparation lecture/écriture pour une instance utilisant une architecture standard. Le serveur proxy identifie intelligemment et transmet les requêtes de lecture et d'écriture des clients. Une fois cette fonctionnalité activée, utilisez n'importe quel client compatible Redis pour vous connecter à l'instance avec séparation lecture/écriture afin d'améliorer les performances de lecture, sans modifier votre application. Les instances avec séparation lecture/écriture activée sont compatibles avec les commandes du protocole Redis, mais certaines restrictions s'appliquent en raison du proxy. Pour plus d'informations, consultez la rubrique Restrictions de commande pour les instances avec séparation lecture/écriture.

• Haute disponibilité

  • Un système de haute disponibilité propriétaire d'Alibaba Cloud surveille automatiquement l'état de santé de tous les nœuds de données afin de garantir la disponibilité de l'instance. Si un nœud principal devient indisponible, le système sélectionne automatiquement un nouveau nœud principal et reconstruit la topologie de réplication. En cas de défaillance d'un réplica en lecture, le système de haute disponibilité détecte automatiquement l'incident, lance un nouveau nœud pour finaliser la synchronisation des données et retire le nœud défaillant.

  • Les serveurs proxy surveillent en temps réel l'état de service de chaque réplica en lecture. Si un réplica en lecture devient indisponible, le proxy réduit automatiquement son poids de service. Si un réplica en lecture échoue plus d'un nombre spécifié de fois consécutives, le proxy suspend le service vers le nœud indisponible. Il continue de surveiller le nœud et reprend le service une fois que celui-ci est rétabli.

• Hautes performances

  Ajoutez des réplicas en lecture pour augmenter linéairement les performances globales d'une instance avec séparation lecture/écriture. Des optimisations au niveau du code source du processus de réplication Redis maximisent la stabilité du système lors de la réplication linéaire et exploitent pleinement les ressources physiques de chaque réplica en lecture.

Cas d'utilisation

Cette fonctionnalité est idéale pour les scénarios présentant un nombre élevé de requêtes de lecture par seconde (QPS). Si votre application est fortement orientée vers les lectures, une instance utilisant une architecture standard risque de ne pas répondre à vos exigences en matière de QPS. Dans ce cas, déployez plusieurs réplicas en lecture pour surmonter le goulot d'étranglement des performances d'un nœud unique. Après activation de la séparation lecture/écriture, le QPS de lecture d'une instance peut être multiplié par neuf.

Séparation lecture/écriture dans une architecture en cluster

Dans une architecture en cluster, vous ne pouvez activer la séparation lecture/écriture que pour les instances cloud-native exécutées en mode proxy. La figure suivante présente un exemple d'architecture.

Recommandations et remarques d'utilisation

• En cas de défaillance d'un réplica en lecture, les requêtes sont transférées vers d'autres nœuds. Si tous les réplicas en lecture deviennent indisponibles, toutes les requêtes de lecture sont envoyées au nœud principal. La défaillance des réplicas en lecture augmente la charge sur le nœud principal, ce qui peut allonger son temps de réponse. Par conséquent, nous vous recommandons d'utiliser plusieurs réplicas en lecture pour les charges de travail à forte intensité de lectures.

• Si un réplica en lecture tombe en panne, le système de haute disponibilité suspend le service vers le nœud défaillant et lance un nouveau réplica en lecture. Ce processus implique l'allocation de ressources, la création d'instance, la synchronisation des données et le chargement du service. Le temps requis dépend de la charge de travail et du volume de données. Tair (Redis OSS-compatible) ne garantit aucun objectif de temps de récupération pour les réplicas en lecture.

• Un déploiement avec séparation lecture/écriture sur deux zones nécessite que la zone primaire dispose d'au moins un nœud principal et d'un réplica en lecture. Avant d'activer la séparation lecture/écriture pour une instance d'architecture standard à deux zones comprenant un nœud principal dans la zone primaire et un nœud de réplication dans la zone secondaire, ajoutez un nœud de réplication à la zone primaire afin qu'elle contienne deux nœuds. Vous pourrez ensuite activer la séparation lecture/écriture.

• Certains scénarios, tels qu'un basculement de haute disponibilité du nœud principal, déclenchent une synchronisation complète des données sur un réplica en lecture. Pendant une synchronisation complète, le réplica en lecture est indisponible et renvoie le message -LOADING Redis is loading the dataset in memory\r\n.

• Certaines commandes de lecture suivent des règles de transfert spécifiques dans l'architecture de séparation lecture/écriture. Par exemple, la commande SCAN est transférée au nœud principal pour exécution, tandis que le proxy répartit uniformément les commandes HSCAN, SSCAN et ZSCAN entre le nœud principal et les réplicas en lecture, selon un calcul modulo basé sur les slots. Pour l'ensemble complet des règles de transfert, consultez la rubrique Règles de routage du proxy.

Prérequis

Avant de commencer, assurez-vous que :

• L'instance est déployée en mode cloud-native

• L'instance est une instance Redis Open-Source Edition ou Tair (Enterprise Edition) optimisée pour la DRAM ou pour la mémoire persistante

• L'instance dispose d'au moins 1 Go de mémoire

• L'instance est une instance haute disponibilité

Procédure

FAQ

• Q : L'activation de la séparation lecture/écriture pour une instance d'architecture standard augmente-t-elle sa bande passante globale ?

  R : Oui. Après activation de la séparation lecture/écriture, la bande passante totale théorique de l'instance correspond à la bande passante de la spécification de l'instance multipliée par le nombre total de nœuds (par exemple, 96 Mo/s × 3 nœuds = 288 Mo/s). Les nœuds proxy ajoutés transfèrent la plupart des requêtes de lecture vers les réplicas en lecture, ce qui réduit la pression sur la bande passante du nœud principal. Toutefois, la bande passante réelle est affectée par des facteurs tels que les requêtes métier et les clients. La bande passante effective est soumise aux résultats des tests de charge.

• Q : Après avoir activé la séparation lecture/écriture pour une instance d'architecture standard, puis-je modifier son architecture pour passer à une architecture en cluster ?

  R : Oui. Vous devez d'abord désactiver la séparation lecture/écriture puis modifier l'architecture de l'instance.

• Q : Comment vérifier si la séparation lecture/écriture est activée ?

  R : Accédez à la page Node Management de l'instance pour vérifier si l'option read/write splitting est activée.

• Q : Pourquoi les requêtes de lecture ne sont-elles pas acheminées vers mes réplicas en lecture ?

  R : Dans une architecture de séparation lecture/écriture sur deux zones, les zones primaire et secondaire disposent de points de terminaison distincts. Les requêtes de lecture sont acheminées uniquement vers le nœud principal ou les réplicas en lecture situés dans la même zone. Si vous utilisez uniquement le point de terminaison de la zone primaire, aucune requête de lecture n'est dirigée vers les réplicas en lecture de la zone secondaire. Pour permettre un accès basé sur la proximité géographique et l'équilibrage de charge, différenciez explicitement les points de terminaison des zones primaire et secondaire dans le code de votre application et acheminez les requêtes destinées à la zone secondaire vers son point de terminaison spécifique.