To ensure the stability of instances and data consistency, you must take note of the limits described in this topic when you use the Global Distributed Cache for Redis feature.

Limits on child instance purchase

  • A new child instance that is added to a distributed instance must reside in a different zone from those of the existing child instances in the distributed instance.
  • A child instance must be a performance-enhanced instance of ApsaraDB for Redis Enhanced Edition (Tair). For more information about performance-enhanced instances, see Performance-enhanced instances.
  • The configurations of a new child instance that is added to a distributed instance must be the same as those of the existing child instances in the distributed instance.
    Warning If the child instances in a distributed instance have different configurations, performance or capacity issues may occur.
  • A distributed instance can contain up to three child instances.

Limits on operations that can be performed on child instances

  • You cannot change the architecture of a child instance in a distributed instance. For example, you cannot change the architecture of a child instance from cluster to standard.
  • To change the configurations of a child instance in a distributed instance, you must change the configurations of all the other child instances in the distributed instance in the same way. Otherwise, performance or capacity issues may occur.
    Notice If a child instance is a read/write splitting instance, you cannot change the configurations of the child instance. For more information about read/write splitting instances, see Read/write splitting instances.
  • When you scale up the configurations of a child instance, you can only double the number of shards. For example, you can change the number of shards only from 8 to 16, not directly to 32.
  • You cannot change the zone of a child instance. For more information, see Migrate an instance across zones.

Limits on commands that can be synchronized

  • The FLUSHDB or FLUSHALL command cannot be synchronized. To clear data, you must run the FLUSHDB or FLUSHALL command on all child instances. Otherwise, data becomes inconsistent on child instances.
  • The Pub and Sub command group cannot be synchronized. We recommend that you use the stream data structure to replicate notification messages across zones. For more information about the Pub and Sub command group, see "Pub and Sub command group" in Pub and Sub command group.
  • The RESTORE command that is synchronized to the destination instance can be run only when the specified key does not exist in the destination instance.

Limits on synchronization granularity

Data is synchronized at the instance level. In other words, all data of a child instance must be synchronized as a whole. Global Distributed Cache for Redis cannot synchronize only some of the data from a child instance to another child instance.
Note If you need to synchronize only some of the data in a child instance, you can modify your business logic.

Limits on data consistency

  • In scenarios where one child instance is writable, such as disaster recovery scenarios, the final data is consistent on all child instances.
  • In scenarios where multiple child instances are writable, such as active geo-redundancy scenarios, make sure that your business system does not modify the same key in multiple child instances at the same time or in a short interval. Otherwise, Global Distributed Cache for Redis cannot ensure that the final values of the key are the same in each child instance, and data inconsistency may occur. The following table describes the types of data inconsistency that may occur.
    Note Global Distributed Cache for Redis does not support conflict-free replicated data types (CRDTs). Make sure the data consistency is kept in your business system.
    Inconsistency Illustration Description
    Value swap Value swap
    1. Child Instance A receives a SET command to set the value of a key to value_A at point in time 1.1 and writes the value to the database at point in time 1.2.
    2. Child Instance B receives a SET command to set the value of the same key to value_B at point in time 2.1 and writes the value to the database at point in time 2.2.
    3. At point in time 3.1, Child Instance A synchronizes data in which the value of the key is value_A to Child Instance B. At the same point in time, Child Instance B synchronizes data in which the value of the key is value_B to Child Instance A.
    4. After the synchronization is complete, the values of the key are swapped on the two child instances.
    Out-of-order data or data loss Out-of-order data or data loss
    1. Child Instance A receives an RPUSH command to push value_A to the list specified by a key at point in time 1.1 and writes the value to the database at point in time 1.2.
    2. Child Instance B receives an RPUSH command to push value_B to the list specified by the same key at point in time 2.1 and writes the value to the database at point in time 2.2.
    3. At point in time 3.1, Child Instance A synchronizes data in which value_A is pushed to the list specified by the key to Child Instance B. At the same point in time, Child Instance B synchronizes data in which value_B is pushed to the list specified by the key to Child Instance A.
    4. After the synchronization is complete, the values in the list are differently ordered on each of the two child instances. If the output of a command depends on the original value of the key on which the command is run, data may be out of order or even lost after the command is synchronized among child instances.
      Note The same issue may occur for other commands including LPUSH, LPOP, APPEND, SORT (STORE), DEL, HDEL, and INCR, and XADD.
    Inconsistent types Inconsistent types
    1. Child Instance A receives a command to set a key to a value of the hash type at point in time 1.1 and writes the value to the database at point in time 1.2.
    2. Child Instance B receives a command to set the same key to a value of the string type at point in time 2.1 and writes the value to the database at point in time 2.2.
    3. At point in time 3, Child Instance A and Child Instance B synchronize data to each other. A conflict occurs during the data synchronization.
    Write conditions unsatisfied Write conditions unsatisfied
    1. Child Instance A receives a SETNX command to set the value of a key to value_A at point in time 1.1 and writes the value to the database at point in time 1.2.
    2. Child Instance B receives a SETNX command to set the value of the same key to value_B at point in time 2.1 and writes the value to the database at point in time 2.2.
    3. At point in time 3, Child Instance A and Child Instance B synchronize data to each other. A conflict occurs during the data synchronization.
      Note The same issue may occur for other commands including SET(NX | XX) and HSETNX.