Redis reference on Docs

Redis command tips

Mon, 01 Jan 0001 00:00:00 +0000

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.

Client-side caching reference

Mon, 01 Jan 0001 00:00:00 +0000

Note:

This document is intended as an in-depth reference for client-side caching. See Client-side caching introduction for general usage guidelines.

Client-side caching is a technique used to create high performance services. It exploits the memory available on application servers, servers that are usually distinct computers compared to the database nodes, to store some subset of the database information directly in the application side.

Sentinel client spec

Mon, 01 Jan 0001 00:00:00 +0000

Redis Sentinel is a monitoring solution for Redis instances that handles automatic failover of Redis masters and service discovery (who is the current master for a given group of instances?). Since Sentinel is both responsible for reconfiguring instances during failovers, and providing configurations to clients connecting to Redis masters or replicas, clients are required to have explicit support for Redis Sentinel.

This document is targeted at Redis clients developers that want to support Sentinel in their clients implementation with the following goals:

Command key specifications

Mon, 01 Jan 0001 00:00:00 +0000

Many of the commands in Redis accept key names as input arguments. The 9th element in the reply of COMMAND (and COMMAND INFO) is an array that consists of the command's key specifications.

A key specification describes a rule for extracting the names of one or more keys from the arguments of a given command. Key specifications provide a robust and flexible mechanism, compared to the first key, last key and step scheme employed until Redis 7.0. Before introducing these specifications, Redis clients had no trivial programmatic means to extract key names for all commands.

Redis serialization protocol specification

Mon, 01 Jan 0001 00:00:00 +0000

To communicate with the Redis server, Redis clients use a protocol called Redis Serialization Protocol (RESP). While the protocol was designed specifically for Redis, you can use it for other client-server software projects.

RESP is a compromise among the following considerations:

Simple to implement.
Fast to parse.
Human readable.

RESP can serialize different data types including integers, strings, and arrays. It also features an error-specific type. A client sends a request to the Redis server as an array of strings. The array's contents are the command and its arguments that the server should execute. The server's reply type is command-specific.

Redis client handling

Mon, 01 Jan 0001 00:00:00 +0000

This document provides information about how Redis handles clients at the network layer level: connections, timeouts, buffers, and other similar topics are covered here.

The information contained in this document is only applicable to Redis version 2.6 or greater.

Accepting Client Connections

Redis accepts clients connections on the configured TCP port and on the Unix socket if enabled. When a new client connection is accepted the following operations are performed:

Key eviction

Mon, 01 Jan 0001 00:00:00 +0000

Redis is commonly used as a cache to speed up read accesses to a slower server or database. Since cache entries are copies of persistently-stored data, it is usually safe to evict them when the cache runs out of memory (they can be cached again in the future if necessary).

Redis lets you specify an eviction policy to evict keys automatically when the size of the cache exceeds a set memory limit. Whenever a client runs a new command that adds more data to the cache, Redis checks the memory usage. If it is greater than the limit, Redis evicts keys according to the chosen eviction policy until the total memory used is back below the limit.

Redis command arguments

Mon, 01 Jan 0001 00:00:00 +0000

The COMMAND DOCS command returns documentation-focused information about available Redis commands. The map reply that the command returns includes the arguments key. This key stores an array that describes the command's arguments.

Every element in the arguments array is a map with the following fields:

name: the argument's name, always present. The name of an argument is given for identification purposes alone. It isn't displayed during the command's syntax rendering. The same name can appear more than once in the entire argument tree, but it is unique compared to other sibling arguments' names. This allows obtaining a unique identifier for each argument (the concatenation of all names in the path from the root to any argument).
display_text: the argument's display string, present in arguments that have a displayable representation (all arguments that aren't oneof/block). This is the string used in the command's syntax rendering.
type: the argument's type, always present. An argument must have one of the following types:
- string: a string argument.
- integer: an integer argument.
- double: a double-precision argument.
- key: a string that represents the name of a key.
- pattern: a string that represents a glob-like pattern.
- unix-time: an integer that represents a Unix timestamp.
- pure-token: an argument is a token, meaning a reserved keyword, which may or may not be provided. Not to be confused with free-text user input.
- oneof: the argument is a container for nested arguments. This type enables choice among several nested arguments (see the XADD example below).
- block: the argument is a container for nested arguments. This type enables grouping arguments and applying a property (such as optional) to all (see the XADD example below).
key_spec_index: this value is available for every argument of the key type. It is a 0-based index of the specification in the command's key specifications that corresponds to the argument.
token: a constant literal that precedes the argument (user input) itself.
summary: a short description of the argument.
since: the debut Redis version of the argument (or for module commands, the module version).
deprecated_since: the Redis version that deprecated the command (or for module commands, the module version).
flags: an array of argument flags. Possible flags are:
- optional: denotes that the argument is optional (for example, the GET clause of the SET command).
- multiple: denotes that the argument may be repeated (such as the key argument of DEL).
- multiple-token: denotes the possible repetition of the argument with its preceding token (see SORT's GET pattern clause).
value: the argument's value. For arguments types other than oneof and block, this is a string that describes the value in the command's syntax. For the oneof and block types, this is an array of nested arguments, each being a map as described in this section.

Example

The trimming clause of XADD, i.e., [MAXLEN|MINID [=|~] threshold [LIMIT count]], is represented at the top-level as block-typed argument.

Redis and the Gopher protocol

Mon, 01 Jan 0001 00:00:00 +0000

** Note: Support for Gopher was removed in Redis 7.0 **

Redis contains an implementation of the Gopher protocol, as specified in the RFC 1436.

The Gopher protocol was very popular in the late '90s. It is an alternative to the web, and the implementation both server and client side is so simple that the Redis server has just 100 lines of code in order to implement this support.

What do you do with Gopher nowadays? Well Gopher never really died, and lately there is a movement in order for the Gopher more hierarchical content composed of just plain text documents to be resurrected. Some want a simpler internet, others believe that the mainstream internet became too much controlled, and it's cool to create an alternative space for people that want a bit of fresh air.