Les instances Tair (compatibles avec Redis OSS) exécutées en architecture cluster ou en architecture lecture/écriture présentent des restrictions de commandes différentes de celles des instances en architecture standard. Certaines commandes sont désactivées et les commandes multi-clés ne peuvent pas accéder aux clés situées dans différents slots. Consultez ces limites avant de migrer vos charges de travail ou d'écrire le code de votre application.
Limites des commandes pour l'architecture cluster
Les instances cluster sont compatibles avec plusieurs versions de Redis. Pour connaître la prise en charge des commandes par version, consultez la rubrique Prise en charge des commandes de l'édition open source Redis ainsi que Prise en charge et limites des commandes de Tair (édition Enterprise).
L'architecture cluster prend en charge deux modes de connexion : le mode de connexion directe et le mode proxy. Les limitations diffèrent selon le mode utilisé.
Mode de connexion directe
SELECT : pris en charge, mais uniquement pour l'initialisation du cluster. Si votre client ne prend pas en charge SELECT lors de l'initialisation du cluster, cette commande n'est pas disponible.
SWAPDB : pris en charge uniquement sur les instances compatibles avec Redis 7.0.
Commandes multi-clés : toutes les clés doivent se trouver dans le même slot. Utilisez des tags de hachage pour regrouper les clés dans le même slot.
Transactions : toutes les clés d'une transaction doivent se trouver dans le même slot, conformément au comportement du cluster Redis open source.
Mode proxy
Le mode proxy ajoute une couche intermédiaire qui masque la topologie du cluster, ce qui améliore la compatibilité du client. Il hérite de toutes les limitations du mode de connexion directe et ajoute les suivantes :
Les requêtes CLIENT INFO et CLIENT ID sont traitées et renvoyées directement par le proxy, quelle que soit la version de Redis.
CLIENT KILL prend en charge deux formats :
CLIENT KILL <ip:port>etCLIENT KILL ADDR <ip:port>.DEL et EXISTS prennent en charge les opérations multi-clés entre différents slots.
SCAN 0 commence à partir du premier shard de données et parcourt chaque shard séquentiellement, en passant au shard suivant uniquement après avoir entièrement analysé le shard actuel. Pour analyser un shard spécifique, utilisez la commande ISCAN.
Les instances cluster en mode proxy prennent en charge les commandes proxy développées par Alibaba Cloud pour la gestion et les opérations. Consultez la rubrique Commandes proxy développées par Alibaba Cloud.
Différences de sortie pour CLIENT LIST
Lorsque vous exécutez CLIENT LIST, le proxy renvoie les informations de connexion pour toutes les connexions au nœud proxy. La sortie diffère de celle de Redis natif comme suit :
| Champ | Comportement |
|---|---|
id, age, idle, addr, fd, name, db, multi, omem, cmd |
Même signification que dans Redis natif |
sub, psub |
Non différenciés sur le nœud proxy ; les deux sont définis sur 1 ou 0 |
qbuf, qbuf-free, obl, oll |
Aucune signification spécifique |
Comportement des transactions en mode proxy
Le comportement des transactions dépend de la distribution des slots des clés concernées :
| Scénario | Résultat |
|---|---|
| Toutes les clés dans le même slot | La transaction s'exécute normalement ; la sémantique complète de la transaction s'applique |
| Clés dans différents slots, mais les clés de chaque commande individuelle dans le même slot | La transaction s'exécute normalement ; la sémantique est garantie par commande, mais pas entre les commandes dont les clés se trouvent dans différents slots |
| Une seule commande avec des clés dans différents slots | La commande ne peut pas être exécutée |
| Commandes sans clé | Certaines ne sont pas prises en charge dans les transactions ; consultez les tableaux de prise en charge des commandes ci-dessous |
De plus, Redis Cluster impose certaines limitations à l'utilisation des scripts Lua. L'architecture cluster de Tair (compatible avec Redis OSS) présente des limitations supplémentaires. Pour plus d'informations, consultez la rubrique Limitations spécifiques à l'architecture cluster.
Limites des commandes pour les instances en architecture lecture/écriture
Les instances en architecture lecture/écriture sont compatibles avec plusieurs versions de Redis. Pour connaître la prise en charge des commandes par version, consultez la rubrique Prise en charge des commandes de l'édition open source Redis ainsi que Prise en charge et limites des commandes de Tair (édition Enterprise).
Les instances en architecture lecture/écriture utilisent le mode proxy par défaut. Elles présentent donc les mêmes restrictions de commandes que les instances cluster en mode proxy. Les requêtes CLIENT INFO et CLIENT ID sont traitées et renvoyées directement par le proxy, quelle que soit la version de Redis.
Les instances en architecture lecture/écriture prennent également en charge les commandes proxy développées par Alibaba Cloud pour la gestion et les opérations. Consultez la rubrique Commandes proxy développées par Alibaba Cloud.
Tableau de prise en charge des commandes pour le mode proxy
Les tableaux suivants s'appliquent à la fois à l'architecture cluster en mode proxy et à l'architecture lecture/écriture.
Légende :
| Symbole | Signification |
|---|---|
| ✔️ | Pris en charge. Pour les commandes multi-clés, les opérations entre différents slots sont autorisées. |
| ⭕️ | Pris en charge avec des limitations. Toutes les clés doivent se trouver dans le même slot (utilisez des tags de hachage). |
| ❌ | Non pris en charge. |
| Note ① | Renvoie OK ou un résultat vide uniquement ; n'est pas réellement exécuté. Inclus pour la compatibilité avec certains frameworks clients. |
| Note ② | Traité et renvoyé directement par le proxy, quelle que soit la version de Redis. |
Bitmap
Gestion du cluster
Gestion des connexions
Générique
Indices géospatiaux
Hachage
HyperLogLog
Listes
Pub/Sub
Scripting et fonctions
Gestion du serveur
Sentinel
Ensemble
Ensemble trié
Stream
Chaîne
Transactions
FAQ
Les instances en architecture cluster et en architecture lecture/écriture en mode proxy prennent-elles en charge la commande WAIT ?
Oui. WAIT est pris en charge dans les versions de proxy 7.1.5 et ultérieures. Si vous utilisez une version antérieure, mettez à niveau la version du proxy.