To ensure instance stability and data consistency, you must take note of the limits described in this topic when you use the Global Distributed Cache feature.
Limits
Each child instance must meet the following requirements:
The instance is deployed in classic mode.
The instance is a DRAM-based instance.
The instance uses the standard or cluster architecture.
NoteMake 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. If the specifications of the child instances in a distributed instance are not all the same, performance or capacity issues may occur.
A distributed instance can contain up to three child instances, and the child instances cannot be located in the same zone. The first child instance can be converted from an existing instance. The second and third child instances must be newly purchased instances.
All child instances of a distributed instance must either reside in the Chinese mainland or be situated in regions outside the Chinese mainland. If you want to synchronize data from the Chinese mainland to regions outside the Chinese mainland, use Data Transmission Service (DTS). For more information, see Apply for permissions to synchronize data across borders.
A child instance of a distributed instance has the following limits:
You cannot change the zone of the instance. For more information, see Migrate an instance across zones.
You cannot change the architecture of the instance, for example, from the cluster architecture to the standard architecture.
When you change the configurations of a cluster instance, you can adjust either the shard specifications or the number of shards. For more information, see Why am I unable to change the configurations of a classic (local disk-based) cluster instance?
Limits on commands that can be synchronized
The FLUSHDB or FLUSHALL command cannot be synchronized.
To clear data, you must run the FLUSHALL command on all child instances. Otherwise, data inconsistency occurs.
To resynchronize data, for example, from Instance A to Instance B, you must remove Instance B from the distributed instance, run the FLUSHALL command on Instance B, and then reconnect Instance B to the distributed instance.
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.
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.
NoteGlobal Distributed Cache does not support conflict-free replicated data types (CRDTs). You must ensure data consistency in your business system.
Inconsistency
Illustration
Description
Value swap
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.
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.
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.
After the synchronization is complete, the values of the key are swapped on the two child instances.
Out-of-order data or data loss
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.
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.
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.
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.
NoteThe same issue may occur for other commands such as
LPUSH,LPOP,APPEND,SORT (STORE),DEL,HDEL,INCR, andXADD.
Inconsistent types
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.
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.
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
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.
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.
At point in time 3, Child Instance A and Child Instance B synchronize data to each other. A conflict occurs during the data synchronization.
NoteThe same issue may occur for other commands such as
SET(NX | XX)andHSETNX.