Proxy Features

Last updated:2026-03-17 16:36:34

Proxy Features

Last updated: 2026-03-17 16:36:34

Tencent Cloud Distributed Cache's Proxy server (Proxy) undertakes core responsibilities such as routing and distribution, CLB, and automatic failover, aiming to simplify client-side processing logic. In-depth analysis of the Proxy's routing mechanism and its handling policies for specific commands will help you build more efficient and robust business architectures.
Proxy Overview
The proxy server (Proxy) operates as an independent component and does not consume the computing resources of data shards. By deploying multiple Proxy nodes, the system not only achieves load balancing (CLB) and failover for traffic but also significantly enhances the availability and scalability of distributed cache database instances.
Features
Description
Routing and Forwarding
The Proxy maintains persistent connections with backend data shards and plays a crucial role in evenly distributing requests and ensuring precise routing, guaranteeing efficient request processing and system stability.
Compatibility with Primary-Secondary Cluster Access Mode
When your business growth exceeds the capacity of the standard architecture, you can seamlessly migrate data to the cluster architecture equipped with Proxy. For non-multi-key operations, compatibility is maintained, allowing for smooth architecture transitions, significantly reducing business adjustment costs, and ensuring continuous business growth. For more information, see Upgrade Instance Architecture.
Seamless Shard Changes
Proxy itself does not directly adjust the number or size of data shards but works in coordination with the backend shard management mechanism to enable elastic scaling of data shards. When data shards need to be migrated (such as during scale-out or scale-in), Proxy supports a transparent data migration process, ensuring that client operations are not affected.

Multiple Databases (DB)

The native Redis protocol and its Cluster client typically support only single-database operations, using only database 0 by default and not providing support for the `SELECT` command. By using Proxy to connect to cluster instances, you can access multiple databases and switch between them using the `SELECT` command. In the cluster edition, each instance provides up to 256 databases by default, offering robust support for the multi-database feature.
Read-Only Replica
In a read-write separation architecture, Proxy continuously monitors the status of read-only nodes to implement traffic management measures in specific scenes:
When a read-only node exhibits abnormal behavior, Proxy reduces its weight, decreasing the proportion of requests it handles. If a connection attempt fails, Proxy refreshes routing and temporarily stops forwarding traffic to that node, rerouting business requests to other nodes until the issue is resolved and the node is reactivated.
If a read-only node is undergoing full data synchronization, Proxy pauses traffic to that node. This pause continues until synchronization is complete, ensuring the node has the latest and consistent data before handling user requests. Once synchronization is complete, Proxy resumes service to that node, allowing it to process requests normally.
Multi-Account Access Control
Proxy can control the types of commands users can execute based on user-defined permissions. Different accounts are granted the ability to execute authorized commands:
Read-only users: Can only execute read commands such as GET, MGET, HGET, SMEMBERS, and so on. Any attempt to execute write commands (such as SET, LPUSH, and SADD) will be rejected by the Redis server.
Read-write users: Users with read-write access can execute all commands, including both read and write operations.
Routing and Forwarding Rules
Forwarding Rules
Description
Basic Forwarding Rules
Cluster Architecture
For commands that operate on a single key, each key is typically stored on one shard, and Proxy will directly forward the request to the slot where the key resides.
For commands involving multiple keys, if the keys are stored on different shards, Proxy will split the command into multiple sub-commands, each handling a single key, and forward each sub-command to the corresponding shard.
Read-Write Separation
Write requests: Since all data modifications should occur on the primary node, Proxy will directly forward write requests to the primary node (Master).
Read requests: Proxy dynamically adjusts the weight of read requests based on the performance and load of the replica nodes, balancing the requests across the replicas. Currently, specific node customization is not supported.
Specific Command Forwarding Rules
Proxy forwards transaction commands (MULTI or EXEC), Lua script commands (EVAL or EVALSHA), SCAN, INFO, and publish/subscribe commands (PUBLISH, SUBSCRIBE, etc.) to the primary node.
Connection Limit Explanation
Under normal circumstances, Proxy establishes persistent connections with data shards to handle requests. When certain commands are involved, Proxy will create additional connections to the corresponding data shards based on the command’s processing requirements. For details on the maximum connection limit for a single data node shard, see Adjust Connection Quantity. To avoid exceeding the connection limit, use the following commands with caution.
Blocking commands: BRPOP, BRPOPLPUSH, BLPOP, BZPOPMAX, BZPOPMIN, BLMPOP, and BZMPOP.
Transaction commands: MULTI, EXEC, and WATCH.
MONITOR commands: MONITOR and IMONITOR.
Subscription commands: SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, and PUNSUBSCRIBE.

Was this page helpful?

You can also Contact Sales or Submit a Ticket for help.

Yes

Feedback

Features	Description
Routing and Forwarding	The Proxy maintains persistent connections with backend data shards and plays a crucial role in evenly distributing requests and ensuring precise routing, guaranteeing efficient request processing and system stability.
Compatibility with Primary-Secondary Cluster Access Mode	When your business growth exceeds the capacity of the standard architecture, you can seamlessly migrate data to the cluster architecture equipped with Proxy. For non-multi-key operations, compatibility is maintained, allowing for smooth architecture transitions, significantly reducing business adjustment costs, and ensuring continuous business growth. For more information, see Upgrade Instance Architecture.
Seamless Shard Changes	Proxy itself does not directly adjust the number or size of data shards but works in coordination with the backend shard management mechanism to enable elastic scaling of data shards. When data shards need to be migrated (such as during scale-out or scale-in), Proxy supports a transparent data migration process, ensuring that client operations are not affected.
Multiple Databases (DB)	The native Redis protocol and its Cluster client typically support only single-database operations, using only database 0 by default and not providing support for the `SELECT` command. By using Proxy to connect to cluster instances, you can access multiple databases and switch between them using the `SELECT` command. In the cluster edition, each instance provides up to 256 databases by default, offering robust support for the multi-database feature.
Read-Only Replica	In a read-write separation architecture, Proxy continuously monitors the status of read-only nodes to implement traffic management measures in specific scenes: When a read-only node exhibits abnormal behavior, Proxy reduces its weight, decreasing the proportion of requests it handles. If a connection attempt fails, Proxy refreshes routing and temporarily stops forwarding traffic to that node, rerouting business requests to other nodes until the issue is resolved and the node is reactivated. If a read-only node is undergoing full data synchronization, Proxy pauses traffic to that node. This pause continues until synchronization is complete, ensuring the node has the latest and consistent data before handling user requests. Once synchronization is complete, Proxy resumes service to that node, allowing it to process requests normally.
Multi-Account Access Control	Proxy can control the types of commands users can execute based on user-defined permissions. Different accounts are granted the ability to execute authorized commands: Read-only users: Can only execute read commands such as GET, MGET, HGET, SMEMBERS, and so on. Any attempt to execute write commands (such as SET, LPUSH, and SADD) will be rejected by the Redis server. Read-write users: Users with read-write access can execute all commands, including both read and write operations.

Forwarding Rules	Description
Basic Forwarding Rules	Cluster Architecture For commands that operate on a single key, each key is typically stored on one shard, and Proxy will directly forward the request to the slot where the key resides. For commands involving multiple keys, if the keys are stored on different shards, Proxy will split the command into multiple sub-commands, each handling a single key, and forward each sub-command to the corresponding shard. Read-Write Separation Write requests: Since all data modifications should occur on the primary node, Proxy will directly forward write requests to the primary node (Master). Read requests: Proxy dynamically adjusts the weight of read requests based on the performance and load of the replica nodes, balancing the requests across the replicas. Currently, specific node customization is not supported.
Specific Command Forwarding Rules	Proxy forwards transaction commands (MULTI or EXEC), Lua script commands (EVAL or EVALSHA), SCAN, INFO, and publish/subscribe commands (PUBLISH, SUBSCRIBE, etc.) to the primary node.

tencent cloud

Proxy Overview

Routing and Forwarding Rules

Connection Limit Explanation