Differences Between the Proxy Architecture and Direct Connection Mode

Last updated:2026-01-28 10:07:37

Differences Between the Proxy Architecture and Direct Connection Mode

Last updated: 2026-01-28 10:07:37

Command
Redis 5.0
Redis 6.2
Redis 7.0
Self-Built Direct Connection Mode
Suggestion
del
Cluster Edition supports cross-slot and cross-node command operations. The Proxy layer automatically completes key distribution and result aggregation.
﻿
﻿
﻿
Cross-slot and cross-node operations are not supported.
Normal use.
unlink
﻿
﻿
﻿
﻿
Normal use.
exists
﻿
﻿
﻿
﻿
Normal use.
mset
﻿
﻿
﻿
﻿
Normal use.
mget
﻿
﻿
﻿
﻿
Normal use.
Note:
Proxy will return an error if the verification of the mget command does not match expectations. -ERR invalid return data.
zunionstore
﻿
﻿
﻿
﻿
Since cross-slot operations require the Proxy to perform additional processing for command distribution and result aggregation, it is recommended to follow Redis community best practices to ensure related keys are placed in the same slot for better performance.
randomkey
The randomkey command in Cluster Edition is randomly forwarded to different backend nodes.
﻿
﻿
It is executed only on the currently connected node.
Recommended to use only when random keys are explicitly required from the current shard; otherwise, use SCAN or other alternatives.
keys
The keys command in Cluster Edition is executed in parallel on all master nodes by default. The Proxy layer aggregates the results from each shard and returns them to the client.
Cluster Edition supports the syntax keys [@shard_id] to specify shard execution. In this case, only the execution result of the target shard is returned, without cross-node aggregation.
The keys command in Standard Edition is directly forwarded to the only master node, with no shard aggregation, and its response behavior is consistent with native Redis.
﻿
﻿
It is executed only on the currently connected node.
Select the execution method of the keys command based on business requirements: shard-specific execution (returns data from a single shard) or all-shard execution (returns aggregated data). Execution methods are as follows:
KEYS {hash_tag}pattern
KEYS pattern NODEID
scan
The scan command in Cluster Edition polls all master nodes by default.
The scan command in Standard Edition is directly forwarded to the master node.
Both Cluster and Standard Editions support execution on specified backend nodes (such as SCAN 0 @shard2).
﻿
﻿
It is executed only on the currently connected node.
Select the execution method of the scan command based on business requirements: shard-specific execution (return data from a single shard) or all-shard execution (return aggregated data). Execution methods are as follows:
SCAN cursor [MATCH {hash_tag}pattern] [COUNT count]
SCAN cursor [MATCH pattern] [COUNT count] NODEID
dbsize
The dbsize command in Cluster Edition is executed on all master nodes by default. The Proxy layer aggregates the results from each shard and returns them to the client.
Cluster Edition supports the syntax dbsize [@shard_id] to specify shard execution. In this case, only the execution result of the target shard is returned, without cross-node aggregation.
The dbsize command in Standard Edition is directly forwarded to the only master node, with no shard aggregation, and its response behavior is consistent with native Redis.
﻿
﻿
It is executed only on the currently connected node.
Select the execution method of the dbsize command based on business requirements: shard-specific execution (returns data from a single shard) or all-shard execution (returns aggregated data). Execution methods are as follows:
DBSIZE
DBSIZE NODEID
flushdb
﻿
The flushdb command in Cluster Edition is executed on all master nodes by default. The Proxy layer aggregates the results from each shard and returns them to the client.
Cluster Edition supports the syntax flushdb [@shard_id] to specify shard execution. In this case, only the execution result of the target shard is returned, without cross-node aggregation.
Versions 6.2 and 7.0 support the ASYNC and SYNC options, with ASYNC as the default.
﻿
﻿
It is executed only on the currently connected node.
Select the execution method of the flushdb command based on business requirements: shard-specific execution (returns data from a single shard) or all-shard execution (returns aggregated data). Command usage is as follows:
FLUSHDB
FLUSHDB SYNC
FLUSHDB ASYNC
FLUSHDB SYNC  NODEID 
FLUSHDB ASYNC NODEID
flushall
The flushall command in Cluster Edition is executed on all master nodes by default. The Proxy layer aggregates the results from each shard and returns them to the client.
Cluster Edition supports the syntax flushall [@shard_id] to specify shard execution. In this case, only the execution result of the target shard is returned, without cross-node aggregation.
Versions 6.2 and 7.0 support the ASYNC and SYNC options, with ASYNC as the default.
﻿
﻿
It is executed only on the currently connected node.
Select the execution method of the flushall command based on business requirements: shard-specific execution (returns data from a single shard) or all-shard execution (returns aggregated data). Command usage is as follows:
FLUSHALL
FLUSHALL SYNC
FLUSHALL ASYNC
FLUSHALL SYNC  NODEID 
FLUSHALL ASYNC NODEID
subscribe
Commands in Cluster Edition are forwarded to all master nodes by default.
Commands in Standard Edition are forwarded to the master node by default.
﻿
﻿
It is executed only on the currently connected node.
Normal use.
unsubscribe
﻿
﻿
﻿
﻿
Normal use.
psubscribe
﻿
﻿
﻿
﻿
Normal use.
punsubscribe
﻿
﻿
﻿
﻿
Normal use.
publish
The publish command in Cluster Edition is routed to the corresponding master node for broadcasting based on the slot value calculated from the channel name.
The publish command in Standard Edition is forwarded to the master node by default.
﻿
﻿
It is executed only on the currently connected node.
Normal use.
pubsub
Supports CHANNELS, NUMPAT, and NUMSUB options.
The pubsub command in Cluster Edition is randomly forwarded to different backend master nodes by default, but the returned results are consistent.
The pubsub command in Standard Edition is forwarded to the master node by default.
﻿
﻿
Executed only on the currently connected node, and different nodes may return different results.
TencentDB for Redis® Cluster Edition enhances the pubsub command. All nodes return a globally consistent channel list, which differs from the open-source version, where nodes return inconsistent results. It is recommended that business code avoid relying on shard-local status and instead process subscriptions on a cluster-wide basis.
cluster
Cluster Edition supports the following commands: cluster keyslot, cluster slots, cluster nodes, cluster info, cluster countkeysinslot, and cluster getkeysinslot.
The cluster slots, cluster nodes, and cluster info commands in Cluster Edition are randomly forwarded to backend nodes by default.
The cluster info command additionally supports execution on a specified backend node.
The cluster keyslot, cluster countkeysinslot, cluster keyslot, and cluster getkeysinslot commands in Cluster Edition are forwarded to the corresponding node based on the specified slot.
Cluster Edition hides or converts certain sensitive information in cluster slots, cluster nodes, and other commands.
﻿
﻿
It is executed only on the currently connected node.
Assess the forwarding mode of cluster commands based on your business scenarios.
asking
The command performs no actual operation in both Cluster Edition and Standard Edition.
﻿
﻿
Execution results in redirection.
Proxy processes ASK errors automatically; users do not need to intervene.
function
-
-
Cluster Edition supports the following commands: function stats, function dump, function list. These commands are randomly forwarded to backend nodes by default.
The function delete, function flush, function kill, function load, and function restore commands are executed synchronously on all master nodes by default, and the client receives a response only after all nodes return consistent results.
It is executed only on the currently connected node.
It is recommended to assess whether cloud-based architecture differs from your business scenarios. If differences exist, modify your code accordingly.
script
In both Cluster Edition and Standard Edition, the script debug command is not supported.
The script exists, script flush, script kill, and script load commands in Cluster Edition are executed synchronously on all master nodes by default, and the client receives a response only after all nodes return consistent results.
The script command in Standard Edition is forwarded to the master node by default.
﻿
﻿
It is executed only on the currently connected node.
Check whether your existing code logic differs from Tencent Cloud's default all-node execution logic. If inconsistencies exist, refactor your code according to cloud specifications.
multi
exec
discard
The backend node locked by a transaction or watch is determined by the hash slot of the first operated key (with watch taking precedence over the first command after multi). This ensures atomic execution of transactions or watch operations within a single node.
Commands in Standard Edition are forwarded to the master node by default.
﻿
﻿
It is executed only on the currently connected node.
It is recommended to assess whether the usage of transactions and the watch command differs from that before migrating to the cloud.
watch
After watch is executed, the connection is locked to the node where the monitored key resides. All subsequent commands are forwarded through this connection.
﻿
﻿
It is executed only on the currently connected node.
It is recommended that key operations between watch and unwatch commands remain within the same slot.
expireat
-
﻿
In both Cluster Edition and Standard Edition, the expireat command does not support any of the following options: NX | XX | GT | LT.
It is executed only on the currently connected node, but supports the following options: NX | XX | GT | LT.
Assess whether your business requires the following options: NX | XX | GT | LT.
pexpire
-
﻿
In both Cluster Edition and Standard Edition, the pexpire command does not support any of the following options: NX | XX | GT | LT.
﻿
﻿
pexpireat
-
﻿
In both Cluster Edition and Standard Edition, the pexpireat command does not support any of the following options: NX | XX | GT | LT.
﻿
﻿
client
Both Cluster Edition and Standard Edition fully support client list, client setname, client getname, client id, client kill, and client unblock commands at the Proxy layer.
The implementation of the client list relies on a dedicated subscription connection: Each Proxy maintains this connection with the master responsible for slot 0. It is used to aggregate session information across all Proxies in real time.
The output of the client list only includes id, addr, fd, name, cmd, age, idle, and proxy fields, with id always being negative. The format differs from the open-source edition.
The client kill command can directly terminate sessions on other Proxies.
﻿
﻿
It is executed only on the currently connected node, returning client list information according to the corresponding Redis version.
Check whether your business relies on the client command. If not required, avoid executing client list to prevent slow queries and excessive node memory usage.
monitor
The monitor command only monitors commands executed on the currently connected Proxy.
﻿
﻿
It is executed only on the currently connected node.
Ensure that you clearly define whether the monitoring target is a single Proxy or metrics of a specific backend shard.
imonitor
The imonitor command in Cluster Edition supports monitoring commands executed on specified backend nodes.
The imonitor command in Standard Edition is forwarded only to the master node.
﻿
﻿
This command is not available.
Use as follows:
Cluster Edition: IMONITOR NODEID
Standard Edition: IMONITOR
time
The time command in Cluster Edition is randomly forwarded to different backend nodes by default.
The time command in Standard Edition is forwarded to the master node by default.
﻿
﻿
It is executed only on the currently connected node.
Assess whether your business depends on the time command.
wait
The wait command in Cluster Edition is forwarded based on the backend master node that processed the last write command.
The wait command in Standard Edition is forwarded to the master node by default.
﻿
﻿
It is executed only on the currently connected node.
Assess the differences between the proxy forwarding logic on the cloud and that in your application code.
command
The command command in Cluster Edition is randomly forwarded to different backend nodes by default.
The command command in Standard Edition is forwarded to the default master node.
﻿
﻿
It is executed only on the currently connected node.
Normal use.
lolwut
The lolwut command in Cluster Edition is randomly forwarded to different backend nodes by default.
The lolwut command in Standard Edition is forwarded to the master node by default.
﻿
﻿
It is executed only on the currently connected node.
Normal use.
echo
The echo command in Cluster Edition is randomly forwarded to different backend master nodes by default.
Commands in Standard Edition are forwarded to the master node by default.
﻿
﻿
It is executed only on the currently connected node.
Normal use.
info
The info command in Cluster Edition is randomly forwarded to backend master nodes by default.
The info command in Standard Edition is forwarded to the master node by default.
The info command also supports specifying a backend node for forwarding.
The info command masks and transforms sensitive information in the response.
﻿
﻿
It is executed only on the currently connected node.
info command usage is as follows:
INFO
INFO NODEID
ping
The ping command in Cluster Edition is randomly forwarded to any backend master node by default.
The ping command additionally supports execution on a specified backend node.
In both Cluster Edition and Standard Edition, the ping command can be processed directly by the Proxy without being forwarded to any backend node.
﻿
﻿
It is executed only on the currently connected node.
Assess whether your business requires forwarding the ping command to backend shards. Command usage is as follows:
PING
PING NODEID
hello
-
In both Cluster Edition and Standard Edition, the hello command currently supports only version 2 and requires the user to execute the Auth command before it can be executed successfully.
Proxy does not support the RESP3 protocol. Executing hello 3 will return an error. Update your client framework to use the RESP2 auth command for authentication.
﻿
It is executed only on the currently connected node.
Assess whether your business framework uses HELLO 3 auth username password for authentication, and whether the RESP3 protocol is used. If so, downgrade to RESP2.
config
In both Cluster Edition and Standard Edition, the config set command is intercepted by the Proxy, which immediately returns a "success" response, but the command does not actually take effect.
The config get command in Cluster Edition is randomly sent to any backend node by default.
By default, the Standard Edition accesses the master node.
﻿
﻿
It is executed only on the currently connected node.
It is recommended to view or modify the configuration via the console. For details, see Parameter Configuration.
slowlog
The slowlog command in Cluster Edition should specify a backend node for execution; otherwise, an error will occur.
The slowlog command in Standard Edition is forwarded to the master node by default.
﻿
﻿
It is executed only on the currently connected node.
It is recommended to view complete slow query information via the console. For details, see Querying Redis Slow Logs.
memory
The memory command is not supported in Cluster Edition.
﻿
﻿
It is executed only on the currently connected node.
It is recommended to view instance Memory Analysis (Large Key Analysis) via the console.
readonly
The readonly command in Cluster Edition is executed on Proxy and returns success, but has no actual effect.
﻿
﻿
It is executed and takes effect only on the currently connected node.
It is recommended to enable replica read-only mode via the console. For details, see Replica Read-Only.
debug
The debug command supports only the object subcommand.
﻿
﻿
All debug subcommands are supported.
It is recommended to assess whether your business uses other debug subcommands. If so, code modification will be required.
sentinel
In both Cluster Edition and Standard Edition, the SENTINEL sentinels, SENTINEL get-master-addr-by-name, and SENTINEL slaves commands are supported but not forwarded to backend nodes.
﻿
﻿
Cluster Edition does not support sentinel mode.
For Cluster Edition, these commands can be ignored.
For sentinel mode, assess whether the supported sentinel commands on cloud Redis meet your business requirements.
role
The role command in Cluster Edition is randomly forwarded to any backend node by default.
Commands in Standard Edition are forwarded to the master node by default.
﻿
﻿
It is executed only on the currently connected node.
It is recommended not to use this command.
lastsave
Commands in Cluster Edition are randomly forwarded to different backend master nodes by default.
Commands in Standard Edition are forwarded to the master node by default.
﻿
﻿
It is executed only on the currently connected node.
It is recommended not to use this command.
latency
Not supported in Cluster Edition.
Commands in Standard Edition are forwarded to the default master node.
﻿
﻿
It is executed only on the currently connected node.
It is recommended not to use this command.
readwrite
The readwrite command is not supported in Cluster Edition.
﻿
﻿
It is executed only on the currently connected node.
It is recommended not to use this command.
pfselftest
The pfselftest command is not supported in Cluster Edition.
﻿
﻿
It is executed only on the currently connected node.
It is recommended not to use this command.
post
The post command is not supported in Cluster Edition.
﻿
﻿
It is executed only on the currently connected node.
It is recommended not to use this command.
host
The host command is not supported in Cluster Edition.
﻿
﻿
It is executed only on the currently connected node.
It is recommended not to use this command.

Was this page helpful?

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

Yes

Feedback

Command	Redis 5.0	Redis 6.2	Redis 7.0	Self-Built Direct Connection Mode	Suggestion
del	Cluster Edition supports cross-slot and cross-node command operations. The Proxy layer automatically completes key distribution and result aggregation.					Cross-slot and cross-node operations are not supported.	Normal use.
unlink								Normal use.
exists								Normal use.
mset								Normal use.
mget								Normal use. Note: Proxy will return an error if the verification of the mget command does not match expectations. `-ERR invalid return data`.
zunionstore								Since cross-slot operations require the Proxy to perform additional processing for command distribution and result aggregation, it is recommended to follow Redis community best practices to ensure related keys are placed in the same slot for better performance.
randomkey	The randomkey command in Cluster Edition is randomly forwarded to different backend nodes.					It is executed only on the currently connected node.	Recommended to use only when random keys are explicitly required from the current shard; otherwise, use SCAN or other alternatives.
keys	The keys command in Cluster Edition is executed in parallel on all master nodes by default. The Proxy layer aggregates the results from each shard and returns them to the client. Cluster Edition supports the syntax `keys [@shard_id]` to specify shard execution. In this case, only the execution result of the target shard is returned, without cross-node aggregation. The keys command in Standard Edition is directly forwarded to the only master node, with no shard aggregation, and its response behavior is consistent with native Redis.					It is executed only on the currently connected node.	Select the execution method of the keys command based on business requirements: shard-specific execution (returns data from a single shard) or all-shard execution (returns aggregated data). Execution methods are as follows: KEYS {hash_tag}pattern KEYS pattern NODEID
scan	The scan command in Cluster Edition polls all master nodes by default. The scan command in Standard Edition is directly forwarded to the master node. Both Cluster and Standard Editions support execution on specified backend nodes (such as `SCAN 0 @shard2`).					It is executed only on the currently connected node.	Select the execution method of the scan command based on business requirements: shard-specific execution (return data from a single shard) or all-shard execution (return aggregated data). Execution methods are as follows: SCAN cursor [MATCH {hash_tag}pattern] [COUNT count] SCAN cursor [MATCH pattern] [COUNT count] NODEID
dbsize	The dbsize command in Cluster Edition is executed on all master nodes by default. The Proxy layer aggregates the results from each shard and returns them to the client. Cluster Edition supports the syntax `dbsize [@shard_id]` to specify shard execution. In this case, only the execution result of the target shard is returned, without cross-node aggregation. The dbsize command in Standard Edition is directly forwarded to the only master node, with no shard aggregation, and its response behavior is consistent with native Redis.					It is executed only on the currently connected node.	Select the execution method of the dbsize command based on business requirements: shard-specific execution (returns data from a single shard) or all-shard execution (returns aggregated data). Execution methods are as follows: DBSIZE DBSIZE NODEID
flushdb	The flushdb command in Cluster Edition is executed on all master nodes by default. The Proxy layer aggregates the results from each shard and returns them to the client. Cluster Edition supports the syntax `flushdb [@shard_id]` to specify shard execution. In this case, only the execution result of the target shard is returned, without cross-node aggregation. Versions 6.2 and 7.0 support the ASYNC and SYNC options, with ASYNC as the default.					It is executed only on the currently connected node.	Select the execution method of the flushdb command based on business requirements: shard-specific execution (returns data from a single shard) or all-shard execution (returns aggregated data). Command usage is as follows: FLUSHDB FLUSHDB SYNC FLUSHDB ASYNC FLUSHDB SYNC NODEID FLUSHDB ASYNC NODEID
flushall	The flushall command in Cluster Edition is executed on all master nodes by default. The Proxy layer aggregates the results from each shard and returns them to the client. Cluster Edition supports the syntax `flushall [@shard_id]` to specify shard execution. In this case, only the execution result of the target shard is returned, without cross-node aggregation. Versions 6.2 and 7.0 support the ASYNC and SYNC options, with ASYNC as the default.					It is executed only on the currently connected node.	Select the execution method of the flushall command based on business requirements: shard-specific execution (returns data from a single shard) or all-shard execution (returns aggregated data). Command usage is as follows: FLUSHALL FLUSHALL SYNC FLUSHALL ASYNC FLUSHALL SYNC NODEID FLUSHALL ASYNC NODEID
subscribe	Commands in Cluster Edition are forwarded to all master nodes by default. Commands in Standard Edition are forwarded to the master node by default.					It is executed only on the currently connected node.	Normal use.
unsubscribe								Normal use.
psubscribe								Normal use.
punsubscribe								Normal use.
publish	The publish command in Cluster Edition is routed to the corresponding master node for broadcasting based on the slot value calculated from the channel name. The publish command in Standard Edition is forwarded to the master node by default.					It is executed only on the currently connected node.	Normal use.
pubsub	Supports CHANNELS, NUMPAT, and NUMSUB options. The pubsub command in Cluster Edition is randomly forwarded to different backend master nodes by default, but the returned results are consistent. The pubsub command in Standard Edition is forwarded to the master node by default.					Executed only on the currently connected node, and different nodes may return different results.	TencentDB for Redis® Cluster Edition enhances the pubsub command. All nodes return a globally consistent channel list, which differs from the open-source version, where nodes return inconsistent results. It is recommended that business code avoid relying on shard-local status and instead process subscriptions on a cluster-wide basis.
cluster	Cluster Edition supports the following commands: cluster keyslot, cluster slots, cluster nodes, cluster info, cluster countkeysinslot, and cluster getkeysinslot. The cluster slots, cluster nodes, and cluster info commands in Cluster Edition are randomly forwarded to backend nodes by default. The cluster info command additionally supports execution on a specified backend node. The cluster keyslot, cluster countkeysinslot, cluster keyslot, and cluster getkeysinslot commands in Cluster Edition are forwarded to the corresponding node based on the specified slot. Cluster Edition hides or converts certain sensitive information in cluster slots, cluster nodes, and other commands.					It is executed only on the currently connected node.	Assess the forwarding mode of cluster commands based on your business scenarios.
asking	The command performs no actual operation in both Cluster Edition and Standard Edition.					Execution results in redirection.	Proxy processes ASK errors automatically; users do not need to intervene.
function	-	-	Cluster Edition supports the following commands: function stats, function dump, function list. These commands are randomly forwarded to backend nodes by default. The function delete, function flush, function kill, function load, and function restore commands are executed synchronously on all master nodes by default, and the client receives a response only after all nodes return consistent results.	It is executed only on the currently connected node.	It is recommended to assess whether cloud-based architecture differs from your business scenarios. If differences exist, modify your code accordingly.
script	In both Cluster Edition and Standard Edition, the script debug command is not supported. The script exists, script flush, script kill, and script load commands in Cluster Edition are executed synchronously on all master nodes by default, and the client receives a response only after all nodes return consistent results. The script command in Standard Edition is forwarded to the master node by default.					It is executed only on the currently connected node.	Check whether your existing code logic differs from Tencent Cloud's default all-node execution logic. If inconsistencies exist, refactor your code according to cloud specifications.
multi exec discard	The backend node locked by a transaction or watch is determined by the hash slot of the first operated key (with watch taking precedence over the first command after multi). This ensures atomic execution of transactions or watch operations within a single node. Commands in Standard Edition are forwarded to the master node by default.					It is executed only on the currently connected node.	It is recommended to assess whether the usage of transactions and the watch command differs from that before migrating to the cloud.
watch	After watch is executed, the connection is locked to the node where the monitored key resides. All subsequent commands are forwarded through this connection.					It is executed only on the currently connected node.	It is recommended that key operations between watch and unwatch commands remain within the same slot.
expireat	-			In both Cluster Edition and Standard Edition, the expireat command does not support any of the following options: NX \| XX \| GT \| LT.	It is executed only on the currently connected node, but supports the following options: NX \| XX \| GT \| LT.	Assess whether your business requires the following options: NX \| XX \| GT \| LT.
pexpire	-			In both Cluster Edition and Standard Edition, the pexpire command does not support any of the following options: NX \| XX \| GT \| LT.
pexpireat	-			In both Cluster Edition and Standard Edition, the pexpireat command does not support any of the following options: NX \| XX \| GT \| LT.
client	Both Cluster Edition and Standard Edition fully support client list, client setname, client getname, client id, client kill, and client unblock commands at the Proxy layer. The implementation of the client list relies on a dedicated subscription connection: Each Proxy maintains this connection with the master responsible for slot 0. It is used to aggregate session information across all Proxies in real time. The output of the client list only includes id, addr, fd, name, cmd, age, idle, and proxy fields, with id always being negative. The format differs from the open-source edition. The client kill command can directly terminate sessions on other Proxies.					It is executed only on the currently connected node, returning client list information according to the corresponding Redis version.	Check whether your business relies on the client command. If not required, avoid executing client list to prevent slow queries and excessive node memory usage.
monitor	The monitor command only monitors commands executed on the currently connected Proxy.					It is executed only on the currently connected node.	Ensure that you clearly define whether the monitoring target is a single Proxy or metrics of a specific backend shard.
imonitor	The imonitor command in Cluster Edition supports monitoring commands executed on specified backend nodes. The imonitor command in Standard Edition is forwarded only to the master node.					This command is not available.	Use as follows: Cluster Edition: IMONITOR NODEID Standard Edition: IMONITOR
time	The time command in Cluster Edition is randomly forwarded to different backend nodes by default. The time command in Standard Edition is forwarded to the master node by default.					It is executed only on the currently connected node.	Assess whether your business depends on the time command.
wait	The wait command in Cluster Edition is forwarded based on the backend master node that processed the last write command. The wait command in Standard Edition is forwarded to the master node by default.					It is executed only on the currently connected node.	Assess the differences between the proxy forwarding logic on the cloud and that in your application code.
command	The command command in Cluster Edition is randomly forwarded to different backend nodes by default. The command command in Standard Edition is forwarded to the default master node.					It is executed only on the currently connected node.	Normal use.
lolwut	The lolwut command in Cluster Edition is randomly forwarded to different backend nodes by default. The lolwut command in Standard Edition is forwarded to the master node by default.					It is executed only on the currently connected node.	Normal use.
echo	The echo command in Cluster Edition is randomly forwarded to different backend master nodes by default. Commands in Standard Edition are forwarded to the master node by default.					It is executed only on the currently connected node.	Normal use.
info	The info command in Cluster Edition is randomly forwarded to backend master nodes by default. The info command in Standard Edition is forwarded to the master node by default. The info command also supports specifying a backend node for forwarding. The info command masks and transforms sensitive information in the response.					It is executed only on the currently connected node.	info command usage is as follows: INFO INFO NODEID
ping	The ping command in Cluster Edition is randomly forwarded to any backend master node by default. The ping command additionally supports execution on a specified backend node. In both Cluster Edition and Standard Edition, the ping command can be processed directly by the Proxy without being forwarded to any backend node.					It is executed only on the currently connected node.	Assess whether your business requires forwarding the ping command to backend shards. Command usage is as follows: PING PING NODEID
hello	-	In both Cluster Edition and Standard Edition, the hello command currently supports only version 2 and requires the user to execute the Auth command before it can be executed successfully. Proxy does not support the RESP3 protocol. Executing hello 3 will return an error. Update your client framework to use the RESP2 auth command for authentication.			It is executed only on the currently connected node.	Assess whether your business framework uses `HELLO 3 auth username password` for authentication, and whether the RESP3 protocol is used. If so, downgrade to RESP2.
config	In both Cluster Edition and Standard Edition, the config set command is intercepted by the Proxy, which immediately returns a "success" response, but the command does not actually take effect. The config get command in Cluster Edition is randomly sent to any backend node by default. By default, the Standard Edition accesses the master node.					It is executed only on the currently connected node.	It is recommended to view or modify the configuration via the console. For details, see Parameter Configuration.
slowlog	The slowlog command in Cluster Edition should specify a backend node for execution; otherwise, an error will occur. The slowlog command in Standard Edition is forwarded to the master node by default.					It is executed only on the currently connected node.	It is recommended to view complete slow query information via the console. For details, see Querying Redis Slow Logs.
memory	The memory command is not supported in Cluster Edition.					It is executed only on the currently connected node.	It is recommended to view instance Memory Analysis (Large Key Analysis) via the console.
readonly	The readonly command in Cluster Edition is executed on Proxy and returns success, but has no actual effect.					It is executed and takes effect only on the currently connected node.	It is recommended to enable replica read-only mode via the console. For details, see Replica Read-Only.
debug	The debug command supports only the object subcommand.					All debug subcommands are supported.	It is recommended to assess whether your business uses other debug subcommands. If so, code modification will be required.
sentinel	In both Cluster Edition and Standard Edition, the SENTINEL sentinels, SENTINEL get-master-addr-by-name, and SENTINEL slaves commands are supported but not forwarded to backend nodes.					Cluster Edition does not support sentinel mode.	For Cluster Edition, these commands can be ignored. For sentinel mode, assess whether the supported sentinel commands on cloud Redis meet your business requirements.
role	The role command in Cluster Edition is randomly forwarded to any backend node by default. Commands in Standard Edition are forwarded to the master node by default.					It is executed only on the currently connected node.	It is recommended not to use this command.
lastsave	Commands in Cluster Edition are randomly forwarded to different backend master nodes by default. Commands in Standard Edition are forwarded to the master node by default.					It is executed only on the currently connected node.	It is recommended not to use this command.
latency	Not supported in Cluster Edition. Commands in Standard Edition are forwarded to the default master node.					It is executed only on the currently connected node.	It is recommended not to use this command.
readwrite	The readwrite command is not supported in Cluster Edition.					It is executed only on the currently connected node.	It is recommended not to use this command.
pfselftest	The pfselftest command is not supported in Cluster Edition.					It is executed only on the currently connected node.	It is recommended not to use this command.
post	The post command is not supported in Cluster Edition.					It is executed only on the currently connected node.	It is recommended not to use this command.
host	The host command is not supported in Cluster Edition.					It is executed only on the currently connected node.	It is recommended not to use this command.

tencent cloud