Command tips are an array of strings. These provide Redis clients with additional information about the command. The information can instruct Redis Cluster clients as to how the command should be executed and its output processed in a clustered deployment.
Unlike the command's flags (see the 3rd element of
COMMAND's reply), which are strictly internal to the server's operation, tips don't serve any purpose other than being reported to clients.
Command tips are arbitrary strings. However, the following sections describe proposed tips and demonstrate the conventions they are likely to adhere to.
This tip indicates that the command's output isn't deterministic.
That means that calls to the command may yield different results with the same arguments and data.
That difference could be the result of the command's random nature (e.g.,
SPOP); the call's timing (e.g.
TTL); or generic differences that relate to the server's state (e.g.
Note: prior to Redis 7.0, this tip was the random command flag.
Note: prior to Redis 7.0, this tip was the sort_for_script flag.
This tip can help clients determine the shard(s) to send the command in clustering mode. The default behavior a client should implement for commands without the request_policy tip is as follows:
In cases where the client should adopt a behavior different than the default, the request_policy tip can be one of:
CONFIG SETcommand. This tip is in-use by commands that don't accept key name arguments. The command operates atomically per shard.
DBSIZEcommand). This tip is in-use by commands that don't accept key name arguments. The command operates atomically per shard.
DEL. However, note that
SUNIONSTOREisn't considered as multi_shard because all of its keys must belong to the same hash slot.
This tip can help clients determine the aggregate they need to compute from the replies of multiple shards in a cluster. The default behavior for commands without a request_policy tip only applies to replies with of nested types (i.e., an array, a set, or a map). The client's implementation for the default behavior should be as follows:
KEYSagainst all shards. These should be packed in a single in no particular order.
MGET's aggregated reply.
The response_policy tip is set for commands that reply with scalar data types, or when it's expected that clients implement a non-default aggregate. This tip can be one of:
SCRIPT KILLcommand that's sent to all shards. Although the script should be loaded in all of the cluster's shards, the
SCRIPT KILLwill typically run only on one at a given time.
SCRIPT EXISTScommand as an example. It returns an array of 0's and 1's that denote the existence of its given SHA1 sums in the script cache. The aggregated response should be 1 only when all shards had reported that a given script SHA1 sum is in their respective cache.
WAITcommand, for example, should be the minimal value (number of synchronized replicas) from all shards.
INFOis an excellent example of that.
redis> command info ping 1) 1) "ping" 2) (integer) -1 3) 1) fast 4) (integer) 0 5) (integer) 0 6) (integer) 0 7) 1) @fast 2) @connection 8) 1) "request_policy:all_shards" 2) "response_policy:all_succeeded" 9) (empty array) 10) (empty array)