Returns @array-reply of details about all Redis commands.
Cluster clients must be aware of key positions in commands so commands can go to matching instances, but Redis commands vary between accepting one key, multiple keys, or even multiple keys separated by other data.
You can use COMMAND
to cache a mapping between commands and key positions for each command to enable exact routing of commands to cluster instances.
Each top-level result contains six nested results. Each nested result is:
Command name is the command returned as a lowercase string.
|
|
Command arity follows a simple pattern:
Command arity includes counting the command name itself.
Examples:
GET
arity is 2 since the command only accepts one argument and always has the format GET _key_
.MGET
arity is -2 since the command accepts at a minimum one argument, but up to an unlimited number: MGET _key1_ [key2] [key3] ...
.Also note with MGET
, the -1 value for “last key position” means the list of keys may have unlimited length.
Command flags is @array-reply containing one or more status replies:
1) 1) "sort"
2) (integer) -2
3) 1) write
2) denyoom
3) movablekeys
4) (integer) 1
5) (integer) 1
6) (integer) 1
Some Redis commands have no predetermined key locations. For those commands, flag movablekeys
is added to the command flags @array-reply. Your Redis Cluster client needs to parse commands marked movablekeys
to locate all relevant key positions.
Complete list of commands currently requiring key location parsing:
SORT
- optional STORE
key, optional BY
weights, optional GET
keysZUNIONSTORE
- keys stop when WEIGHT
or AGGREGATE
startsZINTERSTORE
- keys stop when WEIGHT
or AGGREGATE
startsEVAL
- keys stop after numkeys
count argumentsEVALSHA
- keys stop after numkeys
count argumentsAlso see COMMAND GETKEYS
for getting your Redis server tell you where keys are in any given command.
For most commands the first key is position 1. Position 0 is always the command name itself.
Redis commands usually accept one key, two keys, or an unlimited number of keys.
If a command accepts one key, the first key and last key positions is 1.
If a command accepts two keys (e.g. BRPOPLPUSH
, SMOVE
, RENAME
, …) then the last key position is the location of the last key in the argument list.
If a command accepts an unlimited number of keys, the last key position is -1.
|
|
Key step count allows us to find key positions in commands like MSET
where the format is MSET _key1_ _val1_ [key2] [val2] [key3] [val3]...
.
In the case of MSET
, keys are every other position so the step value is 2. Compare with MGET
above where the step value is just 1.
@return
@array-reply: nested list of command details. Commands are returned in random order.
@examples
COMMAND