Based on the single-node cluster version, DCS Redis active/standby cluster instances adopt an active/standby deployment architecture for each data shard node, meeting business needs for large capacity, high performance, and high reliability. A proxy cluster connects to the Redis cluster through a unified connection address (domain name) and a proxy server forwards client requests to Redis data shards.
Architecture Diagram
Architecture Description
l Load balancer: It adopts active/standby HA mode to receive client requests. The IP address and domain name provided by the Redis cluster instance for access are the load balancer address.
l Proxy: A Redis cluster proxy server evenly distributes client requests to available nodes based on the load of each Redis node to achieve load balancing. At the same time, it monitors the health status of Redis nodes and automatically forwards requests to other available nodes to achieve failover and reduce the impact of single-node faults.
l Redis data shards: Each data shard uses an active/standby dual-node architecture. When the active node fails, the system automatically switches to the standby node within seconds to ensure service continuity.
Features
Data Synchronization
Data consistency is ensured between the active and standby nodes of the DCS instance through incremental data synchronization. When a node fails, the active and standby instances perform a full-data synchronization after recovery from the fault to maintain data consistency.
Automatic Active/Standby Switchover Within Seconds
When the active node fails and becomes unavailable, the system automatically switches to the standby node within 30 seconds. The standby node is then upgraded to the active to restore data access without user operations, thus ensuring service continuity.
Multi-AZ Deployment
Supports multi-AZ deployment upon activation of an instance. The active and standby nodes can be deployed in different AZs. The power and network among nodes are physically isolated. When one of the AZs is unavailable, nodes in the other AZs can continue to provide services, avoiding service unavailability due to single-node faults and further improving data reliability.
Application Scenarios
Large Data Volume
The Redis cluster version supports horizontal scaling with a maximum capacity of 1TB. You can easily add nodes to expand a cluster based on your service requirements.
Scenarios with High QPS Pressure
A Redis cluster is deployed on multiple nodes to break down the performance bottlenecks in single threads, and can better support scenarios with a high QPS.
Throughput-Intensive Application Scenarios
For throughput-intensive scenarios, Redis cluster can meet the high performance and high concurrency requirements with its features such as distributed architecture, horizontal scaling, and concurrent processing.
Scenarios Insensitive to the Redis Protocol
The cluster version architecture has introduced multiple components and has certain limitations in terms of support for the Redis protocol compared to the standard version instances. Therefore, it is not suitable for scenarios that require high Redis protocol compatibility.