All Products
Search
Document Center

ApsaraDB for Redis:Limits

Last Updated:Oct 31, 2023

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 feature.

Limits

  • Child instances must be DRAM-based instances that are deployed in classic (local disk-based) mode.

  • Child instances must use the standard or cluster architecture. You cannot enable the Global Distributed Cache feature for a child instance in the read/write splitting architecture.

  • A distributed instance can contain up to three child instances, and the child instances cannot be located in the same zone.

  • You must make sure that the specifications of each child instance are the same. If you want to change the specifications of a child instance, we recommend that you change all the other child instances to the same specifications.

    Warning

    If the specifications of the child instances in a distributed instance are not all the same, performance or capacity issues may occur.

  • A child instance of a distributed instance has the following limits:

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 commands cannot be synchronized. To replicate notification messages across domains, we recommend that you use the Stream data structure.

  • The RESTORE command that is synchronized to the destination instance can be run only when the destination instance does not contain a key with the same name as the specified one.

Limits on synchronization granularity

Data is synchronized at the instance level. In other words, the data of each child instance must be synchronized as a whole. Global Distributed Cache 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 cannot ensure that the final values of the key are the same in each child instance, and data may pile up in child instances during incremental streaming scenarios. The following table describes the types of data inconsistency that may occur.

    Note

    Global Distributed Cache does not support conflict-free replicated data types (CRDTs). Make sure that data consistency is kept in your business system.

    Inconsistency

    Illustration

    Description

    Value swap

    value互换
    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

    乱序或丢失
    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 such as LPUSH, LPOP, APPEND, SORT (STORE), DEL, HDEL, INCR, and XADD.

    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

    写入条件不满足
    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 such as SET(NX | XX) and HSETNX.