tencent cloud

Feedback

Proxy Features

Last updated: 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.
    Contact Us

    Contact our sales team or business advisors to help your business.

    Technical Support

    Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

    7x24 Phone Support