L'architecture standard de Tair (compatible avec Redis OSS) fonctionne sans mode cluster. Toutes les données sont stockées dans un seul shard, ce qui simplifie l'exploitation, réduit les coûts et assure une compatibilité totale avec le protocole Redis. Contrairement à l'architecture cluster, l'architecture standard ne permet pas d'ajuster le nombre de shards et propose des types d'instance haute disponibilité (plusieurs réplicas) et nœud unique (réplica unique).
Types d'architecture
Deux modes de déploiement sont disponibles : cloud-native et classic.
Architecture standard cloud-native
Une instance cloud-native prend en charge un nœud maître et jusqu'à 9 nœuds réplica. Le nœud maître gère toutes les charges de travail en lecture et en écriture. Les nœuds réplica restent en attente active (hot standby).
En cas de basculement déclenché sur plusieurs zones, le système tente d'abord d'effectuer la commutation au sein de la même zone afin d'éviter tout accès inter-zones pour votre application.
Architecture standard classic
Une instance classic prend en charge un nœud maître et un nœud réplica. Dans un déploiement multi-zones, le nœud réplica est placé dans la zone secondaire.
Fonctionnement
L'architecture standard repose sur un modèle maître-réplica. Le nœud maître gère les charges de travail quotidiennes. Les nœuds réplica restent en attente active.
Lorsque le nœud maître tombe en panne, le système propriétaire de haute disponibilité (HA) détecte la défaillance et effectue un basculement :
Le système HA détecte la panne du nœud maître (échec des E/S disque, panne CPU, etc.).
Un nœud réplica est promu pour devenir le nouveau nœud maître.
L'intégralité du processus de basculement s'achève en moins de 30 secondes.
Architecture standard vs architecture cluster
| Capacité | Architecture standard | Architecture cluster |
|---|---|---|
| Distribution des données | Shard unique | Plusieurs shards |
| Ajustement du nombre de shards | Non pris en charge | Pris en charge |
| Répliques en lecture | Jusqu'à 9 (cloud-native) | Par shard |
| Séparation lecture/écriture | Pris en charge | Pris en charge |
| Compatibilité du protocole Redis | Totale | Partielle (commandes multi-clés restreintes) |
| QPS maximal recommandé | 100 000 | Plus de 200 000 |
| Cas d'utilisation typique | Charges de travail stables sur une instance unique | Charges de travail à haut débit ou à grande échelle |
Fonctionnalités
Fiabilité
Fiabilité du service : les nœuds maître et réplica s'exécutent sur des hôtes physiques distincts. En cas de panne du nœud maître, le système propriétaire de haute disponibilité (HA) effectue automatiquement un basculement.
Fiabilité des données : la persistance des données est activée par défaut ; toutes les données sont écrites sur le disque. La sauvegarde et la restauration sont prises en charge : clonez ou restaurez une instance à partir d'un jeu de sauvegarde pour récupérer des opérations accidentelles. Les instances situées dans des zones dotées de capacités de reprise après sinistre (par exemple, les zones H et I de Hangzhou) prennent en charge la reprise après sinistre au niveau de la zone.
Compatibilité avec le protocole Redis
L'architecture standard est entièrement compatible avec le protocole Redis. Migrez vos charges de travail depuis une base de données Redis auto-gérée vers une instance standard sans interruption de service, en utilisant Alibaba Cloud Data Transmission Service (DTS) pour la migration incrémentielle des données.
Améliorations propriétaires de la réplication
Le mécanisme de réplication maître-réplica d'Alibaba Cloud résout plusieurs limitations de la réplication Redis native :
| Limitation de Redis natif | Solution apportée par Tair |
|---|---|
| La synchronisation complète nécessite un fork, entraînant une latence de quelques millisecondes à plusieurs secondes | Réplication non bloquante : le problème lié au fork est résolu, éliminant ainsi la latence induite par la synchronisation |
| Un échec PSYNC déclenche une synchronisation complète de la base de données Redis (RDB), consommant des E/S disque et du CPU | Des journaux pré-écrits (WAL) répliquent les données entre les nœuds ; les interruptions de réplication ont un impact minimal sur les performances |
| Les processus enfants effectuant une copie sur écriture (COW) consomment la mémoire du nœud maître, risquant des plantages par manque de mémoire | La pression mémoire liée à la COW est éliminée |
| Le transfert de fichiers RDB de plusieurs gigaoctets provoque des pics de trafic sortant et des pointes d'E/S séquentielles | La réplication basée sur les WAL évite les transferts de fichiers volumineux |
Quand utiliser l'architecture standard
QPS inférieur à 100 000 sur une instance unique
Redis natif utilise un modèle mono-thread. L'architecture standard convient à la plupart des charges de travail inférieures à 100 000 requêtes par seconde (QPS). Si vos besoins en QPS augmentent, activez la séparation lecture/écriture ou passez à l'architecture cluster.
Compatibilité totale avec le protocole Redis requise
L'architecture standard prend en charge l'intégralité du protocole Redis, y compris les commandes multi-clés qui sont restreintes en mode cluster. Migrez depuis une base de données Redis auto-gérée ou Redis Sentinel sans modifier le code de votre application.
Redis utilisé comme stockage persistant
La persistance des données, la sauvegarde et la restauration à un instant précis sont intégrées. Utilisez les sauvegardes pour cloner une instance ou effectuer un retour arrière après des modifications accidentelles de données.
Charge de travail à dominante lecture avec peu de commandes de tri ou intensives en calcul
Activez la séparation lecture/écriture pour augmenter le débit en lecture. Pour les charges de travail de tri ou de calcul intensif en CPU à grande échelle, privilégiez plutôt l'architecture cluster.
FAQ
J'exécute Redis en mode Sentinel. Quelle architecture dois-je choisir lors de la migration vers le cloud ?
Choisissez l'architecture standard HA, puis activez le mode compatible Sentinel sur l'instance. Cela vous permet de vous connecter à Tair de la même manière qu'à Redis Sentinel, sans modification du code de l'application.
Mon instance dispose de 8 Go de mémoire avec l'architecture standard. Comment améliorer les performances sans augmenter la mémoire ?
Deux options s'offrent à vous selon le goulot d'étranglement identifié :
Les connexions ou la bande passante constituent le goulot d'étranglement : activez la séparation lecture/écriture. Cette opération ne nécessite aucune modification du code ni changement de point de terminaison, et peut être désactivée à tout moment. L'instance achemine automatiquement les requêtes de lecture et d'écriture vers les nœuds appropriés.
L'utilisation du CPU est constamment élevée : migrez vers une instance cluster. L'ajout de shards répartit la charge CPU sur plusieurs nœuds. Avant la mise à niveau, vérifiez la compatibilité des commandes entre les architectures standard et cluster ; consultez les Limites des commandes prises en charge par les instances cluster et les instances avec séparation lecture/écriture.
Le tableau suivant compare les performances d'une instance Redis Open-Source Edition de 8 Go selon les différentes architectures :
| Architecture | Mémoire (Go) | Cœurs CPU | Bande passante (Mbit/s) | Connexions maximales | Valeur de référence QPS |
|---|---|---|---|---|---|
| Architecture standard (nœuds maître et réplica) | 8 | 2 | 96 | 20 000 | 100 000 |
| Architecture standard (séparation lecture/écriture activée, un nœud maître, un réplica en lecture) | 8 | 4 (2 × 2) | 192 (96 × 2) | 40 000 (20 000 × 2) | 200 000 |
| Architecture cluster (2 shards) | 8 (4 Go × 2 shards) | 4 (2 × 2) | 192 (96 × 2) | 40 000 (20 000 × 2) | 200 000 |