Les instances Tair basées sur la DRAM constituent l'offre haute performance d'ApsaraDB for Redis. Chaque nœud de données offre un débit environ trois fois supérieur à celui d'une instance Redis Open-Source Edition aux spécifications équivalentes, grâce à une architecture multithread qui sépare les opérations d'E/S, l'exécution des commandes et la surveillance sur des threads dédiés. Optez pour les instances basées sur la DRAM lorsque le trafic lié aux clés très sollicitées (hotkeys), la pression en écriture concurrente ou le coût de maintenance du cluster deviennent des goulots d'étranglement.
Avantages
| Avantage | Détails |
|---|---|
| Compatibilité | Entièrement compatible avec les versions 7.0, 6.0 et 5,0 de Redis. Aucune modification du code de l'application n'est requise. |
| Performance | L'architecture multithread offre un nombre de QPS environ trois fois supérieur à celui des instances Redis Open-Source Edition aux mêmes spécifications. La synchronisation complète et incrémentielle des données s'exécute dans les threads d'E/S pour accélérer le processus. |
| Mode de synchronisation | Prend en charge la réplication semi-synchrone. Après l'exécution d'une mise à jour client par le nœud maître, celui-ci réplique les journaux vers un nœud réplica et ne renvoie une réponse qu'après confirmation de réception par le réplica. Cela garantit l'absence de perte de données lors des basculements de haute disponibilité. |
| Architectures de déploiement | Standard, cluster et répartition lecture/écriture. |
| Structures de données étendues | Intègre plusieurs modules Tair propriétaires : exString (y compris les commandes CAS/CAD), exHash, exZset, GIS, Bloom, Doc, TS, Cpc, Roaring, Search et Vector. |
| Fonctionnalités de niveau entreprise | Restauration instantanée des données, cache de requête proxy et Global Distributed Cache. |
| Sécurité des données | Prend en charge le chiffrement SSL et le TDE (Transparent Data Encryption) pour les fichiers RDB. |
Quand utiliser les instances basées sur la DRAM
Choisissez une instance basée sur la DRAM si l'un des scénarios suivants s'applique :
Le nombre de QPS par nœud unique dépasse 100 000 : Les nœuds Redis Open-Source Edition plafonnent entre 80 000 et 100 000 QPS. Les instances basées sur la DRAM gèrent un trafic de clés très sollicitées dépassant 200 000 QPS sans dégradation des performances.
Ventes flash ou pics de trafic : Le modèle multithread absorbe les pics de trafic soudains et maintient des performances stables, évitant ainsi les problèmes de connexion pendant les heures de pointe.
Restrictions liées aux commandes de cluster : Les instances de cluster Redis Open-Source Edition imposent des limites sur les transactions de base de données et les scripts Lua. Les instances de cluster basées sur la DRAM lèvent ces restrictions.
Répartition lecture/écriture avec forte charge d'écriture : La répartition lecture/écriture de Redis Open-Source Edition gère bien les volumes de lecture élevés, mais ne peut pas soutenir de fortes charges d'écriture concurrentes. Les instances basées sur la DRAM en mode répartition lecture/écriture prennent en charge les deux : un nœud de données et jusqu'à cinq réplicas en lecture pour atteindre des millions de QPS.
Réduction des coûts du cluster : Si votre cluster Redis autogéré voit son nombre de nœuds augmenter continuellement, le passage à des instances de cluster basées sur la DRAM peut réduire la taille du cluster des deux tiers et diminuer considérablement les coûts d'exploitation et de maintenance.
Guide de sélection de l'architecture
| Architecture | Redis Open-Source Edition | Instances basées sur la DRAM |
|---|---|---|
| Standard | Inadaptée lorsque le nombre de QPS par nœud unique dépasse 100 000 | Gère un nombre de QPS par nœud unique supérieur à 100 000 |
| Cluster | Les données très sollicitées sur un nœud dégradent les performances des autres données situées sur ce même nœud | Accès haute performance aux données très sollicitées à des coûts de maintenance réduits |
| Répartition lecture/écriture | Débit de lecture élevé ; capacité d'écriture concurrente limitée | Débit de lecture élevé et capacité d'écriture concurrente élevée |
Fonctionnement
Architecture multithread
Redis Open-Source Edition utilise un modèle monothread où un seul thread gère toutes les E/S réseau et l'exécution des commandes. Ce fonctionnement suffit pour des charges modérées, mais devient un goulot d'étranglement en cas de forte concurrence.
Les instances Tair basées sur la DRAM répartissent la charge de travail sur trois types de threads :
Threads d'E/S — lisent les requêtes, analysent les commandes et envoient les réponses
Threads de travail — exécutent les commandes et les événements planifiés
Threads auxiliaires — surveillent les signaux de présence et l'état des nœuds pour assurer la haute disponibilité
Chaque instance prend en charge jusqu'à quatre threads d'E/S fonctionnant simultanément. Des files d'attente et des pipelines sans verrou transfèrent les données entre les threads d'E/S et les threads de travail afin de maximiser les performances du multithreading.
Figure 1. Modèle monothread de Redis — un seul thread gère les requêtes de lecture, l'analyse des requêtes, le traitement des données et les réponses.
Figure 2. Modèle multithread de Tair — les threads d'E/S, de travail et auxiliaires traitent les tâches en parallèle.
Opérations accélérées par le modèle multithread :
| Type d'opération | Accélération |
|---|---|
| Structures de données courantes (String, List, Set, Hash, Sorted Set, HyperLogLog, Geo) | Oui — améliorations significatives |
| Structures de données étendues (modules Tair) | Oui |
| Opérations pub/sub et API bloquantes | Oui — augmentation du débit d'environ 50 %, répliquée dans les threads de travail |
| Transactions et scripts Lua | Non — doivent s'exécuter de manière séquentielle |
Contrairement au multithreading de Redis 6.0, qui améliore les performances jusqu'à deux fois mais consomme beaucoup de ressources CPU, l'architecture Real Multi-IO des instances basées sur la DRAM accélère profondément à la fois les E/S et l'exécution des commandes. Cela offre une meilleure résistance aux impacts sur les connexions et une capacité de débit augmentant de manière linéaire.
Structures de données étendues
Les types de données Redis standard — String, List, Hash, Set, Sorted Set et Stream — couvrent la plupart des cas d'utilisation courants. Pour des scénarios plus complexes tels que les requêtes géospatiales, l'analyse de séries temporelles, la recherche vectorielle ou les structures de données probabilistes, il est généralement nécessaire de modifier les données de l'application ou d'écrire des scripts Lua avec Redis standard.
Les instances basées sur la DRAM intègrent nativement plusieurs modules Tair propriétaires qui ajoutent ces fonctionnalités.
Disponibilité des modules selon la version de Redis :
| Module | Redis 7.0 ou 6,0 | Redis 5.0 |
|---|---|---|
| exString | Oui | Oui |
| exHash | Oui | Oui |
| exZset | Oui | Oui |
| GIS | Oui | Oui |
| Bloom | Oui | Oui |
| Doc | Oui | Oui |
| TS | Oui | Oui |
| Cpc | Oui | Oui |
| Roaring | Oui | Oui |
| Search | Oui | Oui |
| Vector | Oui | Non |
Fonctionnalités de niveau entreprise
| Fonctionnalité | Description |
|---|---|
| Restauration instantanée des données | Tair conserve les données de sauvegarde AOF (append-only file) pendant sept jours maximum. Spécifiez n'importe quel point dans le temps avec une précision à la seconde pour restaurer les données dans une nouvelle instance. |
| Cache de requête proxy | Les nœuds proxy mettent en cache les réponses pour les clés très sollicitées pendant une période de validité configurable. Les requêtes répétées sont servies depuis le cache sans atteindre les shards de données backend. |
| Global Distributed Cache | Un système de redondance géographique active qui permet à plusieurs sites dans différentes régions de servir le trafic simultanément. |
| Synchronisation bidirectionnelle des données via DTS | Le Data Transmission Service (DTS) prend en charge la synchronisation bidirectionnelle des données entre les instances Tair pour les scénarios de redondance géographique active et de reprise après sinistre géographique. Pour les instructions de configuration, consultez la rubrique Configurer la synchronisation bidirectionnelle des données entre les instances Tair. |
FAQ
Mon client ne prend pas en charge les commandes fournies par les modules Tair. Que dois-je faire ?
Définissez les commandes du module dans le code de votre application avant utilisation, ou passez à un client disposant d'une prise en charge intégrée. Pour obtenir la liste des clients compatibles, consultez la rubrique Clients.