Tair (Redis® OSS-Compatible):Limites

Exigences relatives aux instances

• Chaque instance enfant doit être une instance basée sur la DRAM.

• Toutes les instances enfants d'une instance distribuée doivent avoir les mêmes spécifications. Si vous modifiez les spécifications d'une instance enfant, mettez à jour toutes les autres pour qu'elles correspondent. Des spécifications non concordantes entraînent des problèmes de performances ou de capacité.

• Une instance distribuée peut contenir jusqu'à trois instances enfants. Les instances enfants ne peuvent pas se trouver dans la même zone. La première instance enfant peut être convertie à partir d'une instance existante ; les deuxième et troisième doivent être nouvellement achetées.

• Toutes les instances enfants doivent résider soit en Chine continentale, soit dans des régions situées hors de Chine continentale. Pour synchroniser les données de la Chine continentale vers des régions situées hors de Chine continentale, utilisez Data Transmission Service (DTS). Pour plus d'informations, consultez Demander des autorisations pour synchroniser des données transfrontalières.

• Une fois qu'une instance enfant rejoint une instance distribuée, les modifications suivantes sont interdites :

  Attribut	Modification autorisée ?	Notes
  Zone	Non	Ne peut pas être réattribuée après l'intégration
  Architecture	Non	Par exemple, impossible de passer d'une architecture en cluster à une architecture standard
  Configuration des shards (instances en cluster)	Partielle	Vous pouvez ajuster soit les spécifications des shards, soit le nombre de shards, mais pas les deux simultanément. Consultez Pourquoi ne puis-je pas modifier les configurations d'une instance en cluster classique (basée sur des disques locaux) ?

Restrictions de commande

Les commandes suivantes ne sont pas synchronisées entre les instances enfants ou ont un comportement conditionnel. Leur exécution sans comprendre ces restrictions peut entraîner une incohérence permanente des données.

• FLUSHDB et FLUSHALL : Ces commandes ne sont pas synchronisées. L'exécution de l'une ou l'autre commande sur une instance enfant n'affecte pas les autres, laissant les instances dans un état incohérent.

  • Pour effacer toutes les données d'une instance distribuée, exécutez FLUSHALL sur chaque instance enfant individuellement.

  • Pour resynchroniser les données de l'instance A vers l'instance B, supprimez l'instance B de l'instance distribuée, exécutez FLUSHALL sur l'instance B, puis reconnectez l'instance B.

• Commandes Pub/Sub : Les commandes Pub/Sub ne sont pas synchronisées entre les instances enfants. Utilisez plutôt la structure de données Stream pour répliquer les messages de notification entre les zones ou les régions.

• RESTORE : La commande RESTORE s'applique sur l'instance de destination uniquement si aucune clé portant le même nom n'y existe déjà.

• Commandes DEL issues de l'éviction et de l'expiration des données : Les commandes DEL déclenchées par l'éviction des données ou l'expiration des clés ne sont pas synchronisées vers les autres instances enfants. Maintenez l'utilisation de la mémoire dans les limites des spécifications de l'instance pour éviter une éviction inattendue.

Granularité de la synchronisation

Les données sont synchronisées au niveau de l'instance. Chaque instance enfant est toujours synchronisée dans son intégralité ; Global Distributed Cache ne peut pas synchroniser un sous-ensemble de données d'une instance enfant vers une autre.

Cohérence des données

Instances multiples accessibles en écriture

Dans les scénarios où plusieurs instances enfants sont accessibles en écriture simultanément (par exemple, la redondance géographique active), évitez d'écrire sur la même clé depuis plusieurs instances enfants en même temps ou en rapide succession.

Important

Global Distributed Cache ne prend pas en charge les types de données répliqués sans conflit (CRDT). Votre application est responsable de la gestion de la cohérence des données. En règle générale, partitionnez vos données de sorte que chaque clé soit détenue et écrite par une seule instance enfant. Utilisez des lectures inter-instances mais des écritures sur une seule instance pour éliminer les scénarios de conflit décrits ci-dessous.

Le tableau suivant décrit les types d'incohérence des données qui peuvent survenir, leur origine et comment les éviter.

Incohérence	Illustration	Description	Atténuation
Échec du renouvellement de clé		1. Au temps 1, les instances enfants A et B détiennent toutes deux une clé avec un TTL expirant au temps 3. 2. Au temps 2, l'instance enfant A exécute PEXPIREAT pour prolonger la clé jusqu'au temps 5. 3. Au temps 3, la clé de l'instance enfant B expire avant l'arrivée de la commande PEXPIREAT en raison de la latence réseau. 4. Au temps 4, l'instance enfant B reçoit la commande d'extension, mais la clé est déjà supprimée. L'instance enfant A conserve toujours la clé ; l'instance enfant B l'a perdue.	Évitez d'utiliser des TTL sur les clés écrites depuis plusieurs instances, ou assurez-vous qu'une seule instance possède et renouvelle une clé donnée.
Résultats de commande incohérents dus au TTL		En prenant SMOVE comme exemple : 1. Au temps 1, les deux instances détiennent Key1 (expirant au temps 3) et Key2 (sans TTL). 2. Au temps 2, l'instance enfant A exécute SMOVE Key1 Key2 "foo" pour déplacer le membre "foo". 3. Au temps 3, Key1 expire sur les deux instances avant que la commande de synchronisation n'atteigne l'instance enfant B. 4. Au temps 4, l'instance enfant B reçoit la commande SMOVE, mais Key1 a déjà disparu. Key2 dans l'instance enfant A contient "foo" ; Key2 dans l'instance enfant B ne le contient pas.	Évitez les commandes qui opèrent sur des clés avec un TTL via plusieurs instances accessibles en écriture. Effectuez ces opérations depuis une seule instance d'écriture désignée.
Éviction aléatoire des données		1. Au temps 1, les deux instances détiennent Key1 et Key2. 2. Au temps 2, l'instance enfant A manque de mémoire, déclenche l'éviction et supprime aléatoirement Key2. 3. Au temps 3, l'instance enfant B manque de mémoire, déclenche l'éviction et supprime aléatoirement Key1. Étant donné que la politique d'éviction volatile-lru sélectionne les clés indépendamment sur chaque instance et que les suppressions déclenchées par l'éviction ne sont pas synchronisées, les deux instances se retrouvent avec des ensembles de clés différents.	Maintenez l'utilisation de la mémoire dans les limites des spécifications de l'instance. Surveillez l'utilisation de la mémoire et augmentez la capacité avant que l'éviction ne puisse se produire.
Écritures concurrentes — échange de valeurs		Si la même clé est écrite simultanément sur plusieurs instances enfants, les valeurs peuvent être échangées après la synchronisation. 1. Au temps 1, Key:valA est écrit sur l'instance enfant A. 2. Au temps 2, Key:valB est écrit sur l'instance enfant B. 3. Au temps 3, les deux instances se synchronisent simultanément l'une avec l'autre. Après la synchronisation, l'instance enfant A détient Key:valB et l'instance enfant B détient Key:valA.	Attribuez la propriété de la clé à une seule instance. N'écrivez pas la même clé depuis plusieurs instances simultanément.
Écritures concurrentes — conflit de type de données		1. Au temps 1, une clé de type de données Hash est écrite sur l'instance enfant A. 2. Au temps 2, une clé de type de données String est écrite sur l'instance enfant B. 3. Au temps 3, la synchronisation échoue en raison d'un conflit de type de données.	Assurez-vous que chaque clé a un type de données cohérent sur toutes les instances. N'écrivez pas le même nom de clé avec des types de données différents depuis différentes instances.
Écritures concurrentes — conditions d'écriture non satisfaites		1. Au temps 1, SETNX Key valA est écrit sur l'instance enfant A. 2. Au temps 2, SETNX Key valB est écrit sur l'instance enfant B. 3. Au temps 3, la synchronisation échoue car la condition d'écriture (la clé ne doit pas exister) n'est plus satisfaite sur l'instance de réception. Remarque Des commandes telles que HSETNX et SET[NX | XX] peuvent provoquer le même problème.	Utilisez les commandes d'écriture conditionnelle uniquement depuis une seule instance d'écriture désignée. Routez toutes les écritures conditionnelles pour une clé donnée vers une seule instance.
Écritures concurrentes — données désordonnées ou perte de données		1. Au temps 1, RPUSH Key valA est écrit sur l'instance enfant A. 2. Au temps 2, RPUSH Key valB est écrit sur l'instance enfant B. 3. Au temps 3, la synchronisation entraîne des données désordonnées ou perdues. Remarque Des commandes telles que LPUSH, APPEND, DEL, HDEL, INCR et XADD peuvent provoquer le même problème.	Pour les structures de données ordonnées ou en ajout seul, désignez une seule instance d'écriture par clé.