Tencent Cloud

Recent Pages

Proxy Features

最終更新日:2024-11-05 10:05:51

When the cluster architecture and read-write separation of TencentDB for Redis® are used, the Proxy server plays a critical role. It is responsible for executing key tasks such as routing, load balancing, and automatic failover, which simplifies the client's logic processing. Understanding the routing mechanism of Proxy and its handling policies for specific commands will help you build a more efficient business architecture.
Proxy Overview
The Proxy server, as an independent component in the TencentDB for Redis® architecture, does not consume resources from data shards. By deploying multiple Proxy nodes, traffic load balancing and system failover can be achieved, enhancing the availability and scalability of the Redis instance.
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)
Native Redis and its Cluster client typically support operations on a single database, and by default, only use database 0, with no support for the SELECT command. By using Proxy to connect to the cluster instance, access to multiple databases is enabled, and the SELECT command can be used to switch between different databases. In the cluster edition, each instance provides up to 256 databases by default, offering strong 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: Users can only execute read commands such as GET, MGET, HGET, SMEMBERS, etc. Any attempt to execute write commands such as SET, LPUSH, SADD, etc. 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.

お問い合わせ

カスタマーサービスをご提供できるため、ぜひお気軽にお問い合わせくださいませ。

テクニカルサポート

さらにサポートが必要な場合は、サポートチケットを送信して弊社サポートチームにお問い合わせください。24時間365日のサポートをご提供します。

電話サポート（24 時間365日対応）

tencent cloud

Recent Pages

Proxy Features

Proxy Overview

Routing and Forwarding Rules

Connection Limit Explanation

この記事はお役に立ちましたか？

この記事はお役に立ちましたか？

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)	Native Redis and its Cluster client typically support operations on a single database, and by default, only use database 0, with no support for the `SELECT` command. By using Proxy to connect to the cluster instance, access to multiple databases is enabled, and the `SELECT` command can be used to switch between different databases. In the cluster edition, each instance provides up to 256 databases by default, offering strong 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: Users can only execute read commands such as GET, MGET, HGET, SMEMBERS, etc. Any attempt to execute write commands such as SET, LPUSH, SADD, etc. 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

サインアップ

ログイン

Recent Pages

Proxy Features

Proxy Overview

Routing and Forwarding Rules

Connection Limit Explanation

この記事はお役に立ちましたか？

この記事はお役に立ちましたか？