To ensure the stability of instances and data consistency, you must take note of the following limits 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).
  • 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 specifications of a child instance in a distributed instance, you must change the specifications 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.
  • To 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 child instances.

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.
  • 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 in a child instance to another child instance.
Note If you need only to synchronize some of the data in a child instance, you can modify your business logic to use only the data that is required.

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. Global Distributed Cache for Redis cannot ensure that the final values of the key are the same in these child instances. As a result, 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 or data loss Out of order 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 in different orders on the two child instances. If the output of a command depends on the original value of the key on which the command is run, out of order or even data loss may occur after the command is synchronized between 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.