Overview
Baixar
Modo Foco
Tamanho da Fonte
The Tencent Cloud Distributed Cache Redis storage engine supports global replication to ensure data consistency across regions.
Note:
Global replication is currently undergoing an architecture upgrade to further enhance system high availability and cross-region disaster recovery capabilities. It is expected to be available for purchase again in December 2026. Thank you for your patience.
Why Global Replication
When the native code of Redis performs cross-region replication, if the local instance is written excessively or is disconnected from replication for a long time, the
backlog of the master node may not be able to resume the replication, resulting in mandatory full replication by the remote instance. This will block access to and seriously affect the normal business of the remote instance. For more information, see Replication.In addition, Redis' native replication scheme does not mark written nodes in the
backlog, which tends to cause replication loops and data inconsistency when two-way replication is required between the local and remote instances.Implementation Mechanism
Global replication is a new feature added to the open-source version of the kernel by Tencent Cloud. It is fully compatible with Redis 4.0 and Redis 5.0 commands. Based on the original leader-follower replication scheme, a new log file is added for remote replication to ensure the eventual data consistency for instances in any region in the replication group.
Before the log file is replicated by the remote node, the local node will keep it to ensure the continuity of remote replication.
The log file contains the
ServerID to identify the ID of the node to which the log file is written and supports two-way replication to avoid replication loops.The log file contains the command execution timestamp and the version number of the operation
KEY to resolve command conflicts.
Use Cases
Read-only instance and disaster recovery
The Tencent Cloud Distributed Cache Redis global replication solution configures a master instance in a replication group and deploys read-only instances in multiple regions. Disaster recovery instances in different regions replicate data from the master instance. Users can then access data locally to improve data access response speed, enhance user experience, increase data availability, and strengthen data security.
Note:
Shard Quantity: For disaster recovery scenarios, it is recommended that the number of shards in the primary instance and the disaster recovery instance of the global replication group be set to a power of 2, with a maximum value of 64, such as 8, 16, 32, 64. Otherwise, it may lead to uneven shard storage capacity.
Transaction Commands: The transaction operations of global replication, compared to ordinary Redis transactions, will result in a certain degree of database performance degradation.
Multi-Key Commands: In global replication instances, multi-key commands are split by Slot. Compared to non-global replication group database instances, performance decreases, and the decrease ratio is related to the number of splits. The more splits, the greater the performance degradation.
Data Consistency: The version of the data is based on the primary instance, and the level of data consistency is the final data consistency. When the master-slave node link of the primary instance fails, the remote replication of the disaster recovery instance will also be affected by delay. For business scenarios with high database consistency requirements, it is strongly recommended not to perform read operations on the disaster recovery instance.
Eviction Policy: Global replication does not support setting the eviction policy
maxmemory-policy. If eviction is required, use the del command to delete keys.Latency Description: In global replication, the synchronization delay between the master node and the replica node of the primary instance will affect the remote synchronization delay between the primary instance and the disaster recovery instance. The delay duration theoretically does not exceed 500ms.
Monitoring Metrics: Supports monitoring of command quantity deviation during the remote synchronization process between the primary instance and the disaster recovery instance, as well as synchronization delay monitoring. For specific information, please refer to Monitoring Metrics.
Multi-master architecture
If you need to roam and merge data across regions, you need to distribute the same copy of data in multiple regions, read and update data in any region, or merge data from multiple regions. In this case, the database should have the ability to write data in multiple regiRons. In a global replication group, you can configure a multi-master architecture, so data written to one master instance will be synced to other master instances in other regions.
Note:
In a multi-master (global replication) architecture, when processing write commands from local applications or synchronized from other master instances, the Redis master instance does not perform data version detection or timestamp verification. All commands are executed sequentially solely based on the order in which they are received by the local instance.
If the business system updates the same data (Key) across different master instances simultaneously, data inconsistency or unexpected overwrites may occur after global synchronization, and absolute data consistency cannot be guaranteed.
Business Recommendations: Before this feature is enabled, carefully evaluate the business scenarios. During application layer design, it is essential to avoid concurrent updates to the same data across instances (it is recommended to achieve this through data Sharding by region or user routing binding).
Ajuda e Suporte
Esta página foi útil?
Você também pode entrar em contato com a Equipe de vendas ou Enviar um tíquete em caso de ajuda.
comentários