Cluster architecture

Proxy mode (recommended)

The proxy mode simplifies how you connect to and use cluster instances, allowing you to connect to them in the same way as standard architecture instances. The proxy node automatically routes client requests to the correct data shard. The proxy node also provides advanced features such as hotkey caching and automatic failover. For more information, see Tair Proxy features.

The following figures and tables describe the service architecture and components of the proxy mode.

Multi-replica

Service architecture of a multi-replica cluster in proxy mode

Components of the cluster architecture in proxy mode

Component	Description
Proxy node	Routes client requests to the appropriate data shards. A cluster contains multiple proxy nodes that provide services and provide redundancy for disaster recovery.
Data shard	Each data shard uses a high availability architecture with one master node and one to four replica nodes deployed on different physical servers. You can deploy replica nodes in a secondary availability zone. Using multiple replica nodes improves disaster recovery capabilities and reduces the risk of data loss.
High availability (HA)	If a master node fails, the system automatically fails over to a replica node within 30 seconds to ensure service availability and data reliability. If your instance is deployed across two availability zones and a replica node exists in the primary zone, the system prioritizes failing over to that replica node. This prevents latency increases from cross-zone application access.

Single-node

In the single-node cluster architecture, each shard is a single node. If a node fails, the system launches a new, empty Redis process to take its place. After the automatic failover, all data on the failed node is lost. You must warm up the cache again, which can increase the load on your backend database. Your application should implement a cache warmup protection mechanism. This architecture is not recommended for business-critical applications that require high data reliability.

Warning

• The single-node architecture does not guarantee data availability or service continuity. Before you use this architecture, make sure that you understand the risks. We do not recommend using single-node instances in production environments.

• The single-node architecture does not support the following features: automatic or manual backup, offline full key analysis, and Recycle Bin. If data reliability is a requirement, we recommend that you use a multi-replica instance.

Service architecture of a single-node cluster in proxy mode

Components of a cluster in proxy mode

Component	Description
Proxy node	This architecture includes multiple proxy nodes. The system automatically performs load balancing and failover for these nodes.
Data shard	Each data shard is a single node and does not support high availability. If a data node fails, the system launches a new Redis process within 30 seconds to restore service, but all data on the failed node is lost.

Enable read/write splitting

The cloud-native cluster architecture in proxy mode also supports read/write splitting. You can enable this feature when your read traffic is high and exceeds the performance limits of the master node. For more information, see Enable read/write splitting for a cluster instance.

Direct connection mode

In direct connection mode, you connect to your cluster in the same way as a native Redis Cluster. On the initial connection, DNS resolves the client's connection address to the virtual IP address (VIP) of a random data shard. The client then uses the Redis Cluster protocol to access all data shards. The cluster architecture in direct connection mode supports multi-replica and single-node configurations but does not support read/write splitting. The following figure shows the service architecture of this mode.

Service architecture of a cluster in direct connection mode (multi-replica example)

Use cases

• Large data volumes

  Compared with the standard architecture, the cluster architecture can scale its storage capacity up to 16 TB (64 GB × 256 shards). This supports the demands of growing applications.

• High request loads

  The standard architecture cannot handle high request loads. A multi-shard deployment is required to overcome the performance bottleneck of a single shard.

  If the master node is overloaded with read requests, you can enable read/write splitting for the cluster architecture.

  Note

  Only cloud-native cluster instances in proxy mode support read/write splitting. To use this feature, you can migrate data from other instance types by creating a new cluster instance and synchronizing data by using Data Transmission Service (DTS).

• Throughput-intensive applications

  Compared with the standard architecture, the cluster architecture allows you to linearly scale throughput by adding more shards. This provides better support for reading hot data and handling high-throughput workloads.

• Applications with few multi-key operations

  Because a cluster uses a distributed architecture, operations on multiple keys require that all keys reside in the same slot. This restricts certain multi-key operations. For more information, see Command restrictions for cluster instances and read/write splitting instances.

• Latency-sensitive applications

  For an instance deployed across two availability zones, you can add replica nodes to the primary availability zone. For example, you can have one master node and one replica node in the primary zone, and another replica node in the secondary zone. This improves disaster recovery reliability and prevents latency spikes from cross-zone access after a failover.

Usage notes

• A cloud-native cluster instance cannot use proxy mode and direct connection mode simultaneously. We recommend that you use proxy mode.

• The Classic cluster architecture supports only single-replica, dual-replica configurations and does not support read/write splitting.

• A cloud-native cluster instance does not support switching the connection mode directly from direct connection mode to proxy mode. No such switch entry is available in the console. If you need to switch, create a new cluster instance in proxy mode, use Data Transmission Service (DTS) to migrate the data from the original instance to the new instance, verify that the data is consistent, and then switch your application's connection endpoint to the proxy mode endpoint of the new instance.

• A classic cluster instance provides proxy mode by default. If you need to use direct connection mode, you must manually enable it in the console.

Modify cluster configurations

• To add or remove replica nodes, go to the Node Management page of your instance and click Modify.

• To add read replicas, go to the Node Management page of your instance, enable the Read/Write Splitting switch, and then click Modify to add read replicas.

• To add shards, go to the instance details page and select Shard Adjustment > Add Shards from the upper-right corner.

• To change shard specifications, go to the instance details page and select Specification Adjustment > Specification Upgrade/Downgrade from the upper-right corner.

FAQ