Redict

Redis benchmark

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

Redis includes the redis-benchmark utility that simulates running commands done by N clients while at the same time sending M total queries. The utility provides a default set of tests, or you can supply a custom set of tests.

The following options are supported:

Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>]

 -h <hostname>      Server hostname (default 127.0.0.1)
 -p <port>          Server port (default 6379)
 -s <socket>        Server socket (overrides host and port)
 -a <password>      Password for Redis Auth
 -c <clients>       Number of parallel connections (default 50)
 -n <requests>      Total number of requests (default 100000)
 -d <size>          Data size of SET/GET value in bytes (default 3)
 --dbnum <db>       SELECT the specified db number (default 0)
 -k <boolean>       1=keep alive 0=reconnect (default 1)
 -r <keyspacelen>   Use random keys for SET/GET/INCR, random values for SADD
  Using this option the benchmark will expand the string __rand_int__
  inside an argument with a 12 digits number in the specified range
  from 0 to keyspacelen-1. The substitution changes every time a command
  is executed. Default tests use this to hit random keys in the
  specified range.
 -P <numreq>        Pipeline <numreq> requests. Default 1 (no pipeline).
 -q                 Quiet. Just show query/sec values
 --csv              Output in CSV format
 -l                 Loop. Run the tests forever
 -t <tests>         Only run the comma separated list of tests. The test
                    names are the same as the ones produced as output.
 -I                 Idle mode. Just open N idle connections and wait.

You need to have a running Redis instance before launching the benchmark. You can run the benchmarking utility like so:

Community Redict modules

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

Community Modules for Redict #

Redict Modules allow you to extend the functionality of Redict with native code. For details on writing new modules, see Introduction to Redict Modules.

Note: Redict is broadly compatible with Redis® Modules* compatible with Redis® versions 7.2.4 and earlier in source and binary form. See Compatibility with Redis® for details.

Executing Lua scripts

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

Executing Lua scripts in Redict #

Redict lets users upload and execute Lua scripts on the server. Scripts can employ programmatic control structures and use most of the commands while executing to access the database. Because scripts execute in the server, reading and writing data from scripts is very efficient.

Redict guarantees the script’s atomic execution. While executing the script, all server activities are blocked during its entire runtime. These semantics mean that all of the script’s effects either have yet to happen or had already happened.

Migrating packages

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

Migrating your distribution to Redict #

This page is intended for maintainers of downstream Redis® packages in large software distributions which are deprecating their Redis® package due to the license change and looking to provide Redict to their users as a replacement.

Build system changes #

The build system is largely unchanged from Redis® 7.2.4. Your build scripts can be updated by simply replacing the source tarball with the appropriate Codeberg release, then replacing “redis” with “redict” throughout.

Redict modules and blocking commands

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

Redict modules and blocking commands #

Redict has a few blocking commands among the built-in set of commands. One of the most used is BLPOP (or the symmetric BRPOP) which blocks waiting for elements arriving in a list.

The interesting fact about blocking commands is that they do not block the whole server, but just the client calling them. Usually the reason to block is that we expect some external event to happen: this can be some change in the Redict data structures like in the BLPOP case, a long computation happening in a thread, to receive some data from the network, and so forth.

Migrating containers

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

Migrating to Redict containers #

For complete details on installing and using Redict containers, see Usage with containers.

Redict differs from Redis® container in that the “latest” image and images based on it (e.g. “7.3.1”) refer to images based on “scratch” rather than Debian. Debian- and Alpine-based containers are available and broadly compatible with Redis® containers, but you may wish to consider the opportunity to migrate to a scratch container if you do not depend on any Debian- or Alpine-specific features being available.

Modules API for native types

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

Modules API for native types #

Redict modules can access Redict built-in data structures both at high level, by calling Redict commands, and at low level, by manipulating the data structures directly.

By using these capabilities in order to build new abstractions on top of existing Redict data structures, or by using strings DMA in order to encode modules data structures into Redict strings, it is possible to create modules that feel like they are exporting new data types. However, for more complex problems, this is not enough, and the implementation of new data structures inside the module is needed.

Using Lua functions

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

Redict Functions #

Redict Functions is an API for managing code to be executed on the server. They are an evolutionary step from ephemeral scripting.

Functions provide the same core functionality as scripts but are first-class software artifacts of the database. Redict manages functions as an integral part of the database and ensures their availability via data persistence and replication. Because functions are part of the database and therefore declared before use, applications aren’t required to load them during runtime nor risk aborted transactions. An application that uses functions depends only on their APIs rather than on the embedded script logic in the database.

Debugging Lua scripts

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

Debugging Lua scripts in Redict #

Redict includes a complete Lua debugger, that can be used in order to make the task of writing complex Redict scripts much simpler.

Note: Please make sure to avoid debugging Lua scripts using your Redict production server. Use a development server instead. Also note that using the synchronous debugging mode (which is NOT the default) results in the Redict server blocking for all the time the debugging session lasts.

API reference

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

Redict Lua API reference #

Redict includes an embedded Lua 5.1 interpreter. The interpreter runs user-defined ephemeral scripts and functions. Scripts run in a sandboxed context and can only access specific Lua packages. This page describes the packages and APIs available inside the execution’s context.

Sandbox context #

The sandboxed Lua context attempts to prevent accidental misuse and reduce potential threats from the server’s environment.

Scripts should never try to access the Redict server’s underlying host systems. That includes the file system, network, and any other attempt to perform a system call other than those supported by the API.

Community resources

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

Engaging with the community #

There are many ways to engage with the Redict community. Note that the Redict project has adopted the Contributor Covenant Code of Conduct.

Repository and issue tracker #

The Redict project is hosted on Codeberg. The code, documentation, and website have individual repositories with their own issue trackers.

No contributor license agreement (CLA) or contribution assignment agreement (CAA) is required for contributing to any part of the Redict project.

About the license

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

About the license #

Redict is distributed using the Lesser GNU General Public License, aka LGPL-3.0-only, and is based on the Redis®¹ OSS 7.2.4 3-Clause BSD licensed source code.

LGPL is a copyleft license. The following is no substitute for the advice of a lawyer, particularly in more complex scenarios, but it suffices to summarize the basic functions of this license for those unfamiliar with the concept.

Tip: Commercial and non-commercial users of Redict are not required to publish or otherwise “open source” the source code of Redict, including any private modifications they make to the source code, nor are they required to publish the source code of any software they use in combination with Redict.

Redict 7.3.6 is now available

Wed, 08 Oct 2025 00:00:00 +0000

Redict 7.3.6 is now available and includes important security updates. Deployments which allow authenticated, untrusted users access to the Redict database are asked to upgrade urgently.

You may download the release on Codeberg, or update your official container images via registry.redict.io.

Redict 7.3.6 includes fixes for the following security vulnerabilities:

No other changes are included in this release.

The SHA-256 checksum of the Redict 7.3.6 release tarball is 3d6aedad01f8137beeb2aabc74c128b4eec9a2d0d4433892b855fb2f4e6f39f2.

Redict 7.3.5 is now available

Mon, 14 Jul 2025 00:00:00 +0000

Redict 7.3.5 is now available and includes security updates of moderate importance. Deployments which allow authenticated, untrusted users access to the Redict database are asked to upgrade urgently.

You may download the release on Codeberg, or update your official container images via registry.redict.io.

Redict 7.3.5 includes fixes for the following security vulnerabilities:

CVE-2025-32023

No other changes are included in this release.

The SHA-256 checksum of the Redict 7.3.5 release tarball is 1528db77c3539190ebe1fe3963347e02ac8095aff75a19b3373cddcf3f920405.

Redict 7.3.4 is now available

Fri, 11 Jul 2025 00:00:00 +0000

Redict 7.3.4 is now available and includes minor security updates. You may download the release on Codeberg, or update your official container images via registry.redict.io.

Redict 7.3.4 includes fixes for the following security vulnerabilities:

CVE-2025-48367

No other changes are included in this release.

The SHA-256 checksum of the Redict 7.3.4 release tarball is 6c7e60b8b10a46f6fce8ccaaf1d6bf9d0db796a4d6169422c34dedbf8a4cb680.

Redict 7.3.3 is now available for urgent deployment

Mon, 05 May 2025 00:00:00 +0000

Redict 7.3.3 is now available and includes important security updates. You may download the release on Codeberg, or update your official container images via registry.redict.io.

Redict 7.3.3 includes fixes for the following security vulnerabilities:

CVE-2025-21605

No other changes are included in this release.

The SHA-256 checksum of the Redict 7.3.3 release tarball is 5f96a35620f134ff8d3e91fe9b63ef2f45d343b12b94790ba61cdf2178516b26.

Redict 7.3.2 is now available for urgent deployment

Wed, 08 Jan 2025 00:00:00 +0000

Redict 7.3.2 is now available and includes important security updates. You may download the release on Codeberg, or update your official container images via registry.redict.io.

Redict 7.3.2 includes fixes for the following security vulnerabilities:

No other changes are included in this release.

The SHA-256 checksum of the Redict 7.3.2 release tarball is c00ddb7d9eea879b3effc3dd7d1a8cff954fb472915ab9002ec56068c3af2a73.

Redict 7.3.1 is now available for urgent deployment

Tue, 01 Oct 2024 00:00:00 +0000

Redict 7.3.1 is now available and includes important security updates. You may download the release on Codeberg, or update your official container images via registry.redict.io.

Redict 7.3.1 includes fixes for the following security vulnerabilities:

No other changes are included in this release.

The SHA-256 checksum of the Redict 7.3.1 release tarball is 6dbe80d28503a9252048ab81856efcfec109cdf3f924e840411c30237cf8f634.

Early notice for Redict 7.3.1 security release

Mon, 16 Sep 2024 00:00:00 +0000

Please be advised that Redict version 7.3.1 is scheduled for release on October 1st and includes changes which address the following vulnerabilities (currently under embargo):

CVE-2024-31449
CVE-2024-31227
CVE-2024-31228

Users are encouraged to upgrade their Redict installation urgently once the release is available on October 1st.

Redict 7.3.0 is now available

Wed, 03 Apr 2024 00:00:00 +0000

The Redict community is pleased to announce the release of Redict 7.3.0, the first stable version of our copyleft fork of Redis® OSS 7.2.4.¹ You can download the release on Codeberg, or download one of our official container images from registry.redict.io.

We have written comprehensive documentation detailing our compatibility with Redis® OSS 7.2.4, which also provides detailed documentation for various migration scenarios, such as for users of the official Redis® containers on Docker Hub, downstream package maintainers, and so on.

Redict release candidate 7.3.0-rc1 is now available: call for testing

Tue, 26 Mar 2024 00:00:00 +0000

The initial release candidate for Redict’s first general release, 7.3.0-rc1, is now available for download and testing. You can find the release on Codeberg:

Redict 7.3.0-rc1

Update: 7.3.0-rc2 is now available, with two minor changes from rc1:

Redict 7.3.0-rc2

First time here? Redict is an independent fork of Redis®* OSS 7.2.4 licensed under the Lesser GNU General Public license (LGPL-3.0-only). Redict is not affiliated with Redis®. See the announcement for more details.

Redict is an independent, copyleft fork of Redis®

Fri, 22 Mar 2024 00:00:00 +0000

Like many of you, I was disappointed when I learned that Redis®¹ was changing to a non-free licensing model. This is a betrayal of the free software community, but perhaps not an entirely surprising one. Forks are likely to start appearing in the coming days, and today, I would like to offer Redict to you as a possible future home for your needs, and present its trade-offs as compared to the other forks you’re likely to be choosing from soon.

ACL

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

ACL

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

Redict Access Control List #

The Redict ACL, short for Access Control List, is the feature that allows certain connections to be limited in terms of the commands that can be executed and the keys that can be accessed. The way it works is that, after connecting, a client is required to provide a username and a valid password to authenticate. If authentication succeeded, the connection is associated with a given user and the limits the user has. Redict can be configured so that new connections are already authenticated with a “default” user (this is the default configuration). Configuring the default user has, as a side effect, the ability to provide only a specific subset of functionalities to connections that are not explicitly authenticated.

ACL CAT

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

ACL DELUSER

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

ACL DRYRUN

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

ACL GENPASS

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

ACL GETUSER

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

ACL HELP

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

ACL LIST

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

ACL LOAD

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

ACL LOG

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

ACL SAVE

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

ACL SETUSER

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

ACL USERS

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

ACL WHOAMI

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

API reference

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

Modules API reference #

Heap allocation raw functions #

Memory allocated with these functions are taken into account by Redict key eviction algorithms and are reported in Redict memory usage information.

`RedictModule_Alloc` #

void *RedictModule_Alloc(size_t bytes);

Available since: Redict 7.3.0

Use like malloc(). Memory allocated with this function is reported in Redict INFO memory, used for keys eviction according to maxmemory settings and in general is taken into account as memory allocated by Redict. You should avoid using malloc(). This function panics if unable to allocate enough memory.

APPEND

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

ASKING

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

AUTH

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

BGREWRITEAOF

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

BGSAVE

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

BITCOUNT

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

BITFIELD

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

BITFIELD_RO

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

Redict bitfields

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

Introduction to Redict Bitfields #

Redict bitfields let you set, increment, and get integer values of arbitrary bit length. For example, you can operate on anything from unsigned 1-bit integers to signed 63-bit integers.

These values are stored using binary-encoded Redict strings. Bitfields support atomic read, write and increment operations, making them a good choice for managing counters and similar numerical values.

Basic commands #

BITFIELD atomically sets, increments and reads one or more values.
BITFIELD_RO is a read-only variant of BITFIELD.

Example #

Suppose you want to maintain two metrics for various bicycles: the current price and the number of owners over time. You can represent these counters with a 32-bit wide bitfield per for each bike.

Redict bitmaps

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

Introduction to Redict Bitmaps #

Bitmaps are not an actual data type, but a set of bit-oriented operations defined on the String type which is treated like a bit vector. Since strings are binary safe blobs and their maximum length is 512 MB, they are suitable to set up to 2^32 different bits.

You can perform bitwise operations on one or more strings. Some examples of bitmap use cases include:

BITOP

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

BITPOS

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

BLMOVE

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

BLMPOP

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

BLPOP

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

BRPOP

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

BRPOPLPUSH

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

Bulk Loading

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

Writing Data in Bulk Using the Redict Protocol #

Bulk loading is the process of loading Redict with a large amount of pre-existing data. This document describes how to bulk-load data in Redict quickly and efficiently.

Bulk loading using the redict-cli #

Using a normal Redict client to perform bulk loading is not a good idea for a few reasons: the naive approach of sending one command after the other is slow due to the round-trip time for every command. It is possible to use pipelining, but for bulk loading of many records, new commands need to be written while replies are read.

BZMPOP

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

BZPOPMAX

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

BZPOPMIN

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

CLIENT

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

CLIENT CACHING

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

CLIENT GETNAME

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

CLIENT GETREDIR

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

CLIENT HELP

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

CLIENT ID

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

CLIENT INFO

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

CLIENT KILL

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

CLIENT LIST

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

CLIENT NO-EVICT

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

CLIENT NO-TOUCH

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

CLIENT PAUSE

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

CLIENT REPLY

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

CLIENT SETINFO

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

CLIENT SETNAME

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

CLIENT TRACKING

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

CLIENT TRACKINGINFO

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

CLIENT UNBLOCK

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

CLIENT UNPAUSE

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

Client-side caching in Redict

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

Server-assisted, client-side caching in Redict #

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.

Normally when data is required, the application servers ask the database about such information, like in the following diagram:

+-------------+                                +----------+
|             | ------- GET user:1234 -------> |          |
| Application |                                | Database |
|             | <---- username = Alice ------- |          |
+-------------+                                +----------+

When client-side caching is used, the application will store the reply of popular queries directly inside the application memory, so that it can reuse such replies later, without contacting the database again:

Redict Cluster

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

Horizontal Scaling with Redict Cluster #

Redict scales horizontally with a deployment topology called Redict Cluster. This topic will teach you how to set up, test, and operate Redict Cluster in production. You will learn about the availability and consistency characteristics of Redict Cluster from the end user’s point of view.

If you plan to run a production Redict Cluster deployment or want to understand better how Redict Cluster works internally, consult the Redict Cluster specification.

CLUSTER

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

CLUSTER ADDSLOTS

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

CLUSTER ADDSLOTSRANGE

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

CLUSTER BUMPEPOCH

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

CLUSTER COUNT-FAILURE-REPORTS

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

CLUSTER COUNTKEYSINSLOT

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

CLUSTER DELSLOTS

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

CLUSTER DELSLOTSRANGE

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

CLUSTER FAILOVER

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

CLUSTER FLUSHSLOTS

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

CLUSTER FORGET

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

CLUSTER GETKEYSINSLOT

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

CLUSTER HELP

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

CLUSTER INFO

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

CLUSTER KEYSLOT

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

CLUSTER LINKS

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

CLUSTER MEET

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

CLUSTER MYID

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

CLUSTER MYSHARDID

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

CLUSTER NODES

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

CLUSTER REPLICAS

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

CLUSTER REPLICATE

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

CLUSTER RESET

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

CLUSTER SAVECONFIG

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

CLUSTER SET-CONFIG-EPOCH

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

CLUSTER SETSLOT

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

CLUSTER SHARDS

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

CLUSTER SLAVES

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

CLUSTER SLOTS

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

COMMAND

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

Redict Command Arguments

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

How Redict commands expose their documentation programmatically #

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.

COMMAND COUNT

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

COMMAND DOCS

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

COMMAND GETKEYS

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

COMMAND GETKEYSANDFLAGS

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

COMMAND HELP

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

COMMAND INFO

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

Command key specifications

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

What are command key specification and how to use them in your client #

Many of the commands in Redict 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 to extract key names for all commands.

COMMAND LIST

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

Redict command tips

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

Command Tips #

Command tips are an array of strings. These provide Redict clients with additional information about the command. The information can instruct Redict 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.

CONFIG

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

CONFIG GET

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

CONFIG HELP

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

CONFIG RESETSTAT

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

CONFIG REWRITE

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

CONFIG SET

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

Redict configuration

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

Configuration #

Redict is able to start without a configuration file using a built-in default configuration, however this setup is only recommended for testing and development purposes.

The proper way to configure Redict is by providing a Redict configuration file, usually called redict.conf.

The redict.conf file contains a number of directives that have a very simple format:

keyword argument1 argument2 ... argumentN

This is an example of a configuration directive:

COPY

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

Redict CPU profiling

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

Performance Engineering Guide #

Filling the performance checklist #

Redict is developed with a great emphasis on performance. We do our best with every release to make sure you’ll experience a very stable and fast product.

Nevertheless, if you’re finding room to improve the efficiency of Redict or are pursuing a performance regression investigation you will need a concise methodical way of monitoring and analyzing Redict performance.

To do so you can rely on different methodologies (some more suited than other depending on the class of issues/analysis we intend to make). A curated list of methodologies and their steps are enumerated by Brendan Greg at the following link.

DBSIZE

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

DEBUG

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

Debugging

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

Debugging #

Redict is developed with an emphasis on stability. We do our best with every release to make sure you’ll experience a stable product with no crashes. However, if you ever need to debug the Redict process itself, read on.

When Redict crashes, it produces a detailed report of what happened. However, sometimes looking at the crash report is not enough, nor is it possible for the Redict core team to reproduce the issue independently. In this scenario, we need help from the user who can reproduce the issue.

DECR

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

DECRBY

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

DEL

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

DISCARD

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

Distributed Locks

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

A Distributed Lock Pattern with Redict #

Distributed locks are a very useful primitive in many environments where different processes must operate with shared resources in a mutually exclusive way.

There are a number of libraries and blog posts describing how to implement a DLM (Distributed Lock Manager) with Redict, but every library uses a different approach, and many use a simple approach with lower guarantees compared to what can be achieved with slightly more complex designs.

DUMP

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

ECHO

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

EVAL

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

EVAL_RO

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

EVALSHA

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

EVALSHA_RO

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

EXEC

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

EXISTS

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

EXPIRE

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

EXPIREAT

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

EXPIRETIME

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

FAILOVER

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

Redict FAQ

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

FAQ #

How is Redict different from other key-value stores? #

Redict has a different evolution path in the key-value DBs where values can contain more complex data types, with atomic operations defined on those data types. Redict data types are closely related to fundamental data structures and are exposed to the programmer as such, without additional abstraction layers.
Redict is an in-memory but persistent on disk database, so it represents a different trade off where very high write and read speed is achieved with the limitation of data sets that can’t be larger than memory. Another advantage of in-memory databases is that the memory representation of complex data structures is much simpler to manipulate compared to the same data structures on disk, so Redict can do a lot with little internal complexity. At the same time the two on-disk storage formats (RDB and AOF) don’t need to be suitable for random access, so they are compact and always generated in an append-only fashion (Even the AOF log rotation is an append-only operation, since the new version is generated from the copy of data in memory). However this design also involves different challenges compared to traditional on-disk stores. Being the main data representation on memory, Redict operations must be carefully handled to make sure there is always an updated version of the data set on disk.

What’s the Redict memory footprint? #

To give you a few examples (all obtained using 64-bit instances):

FCALL

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

FCALL_RO

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

FLUSHALL

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

FLUSHDB

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

FUNCTION

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

FUNCTION DELETE

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

FUNCTION DUMP

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

FUNCTION FLUSH

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

FUNCTION HELP

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

FUNCTION KILL

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

FUNCTION LIST

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

FUNCTION LOAD

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

FUNCTION RESTORE

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

FUNCTION STATS

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

GEOADD

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

GEODIST

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

GEOHASH

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

GEOPOS

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

GEORADIUS

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

GEORADIUS_RO

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

GEORADIUSBYMEMBER

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

GEORADIUSBYMEMBER_RO

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

GEOSEARCH

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

GEOSEARCHSTORE

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

Redict geospatial

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

Introduction to Redict Geospatial #

Redict geospatial indexes let you store coordinates and search for them. This data structure is useful for finding nearby points within a given radius or bounding box.

Basic commands #

GEOADD adds a location to a given geospatial index (note that longitude comes before latitude with this command).
GEOSEARCH returns locations with a given radius or a bounding box.

See the complete list of geospatial index commands.

GET

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

GETBIT

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

GETDEL

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

GETEX

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

GETRANGE

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

GETSET

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

Redict hashes

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

Introduction to Redict Hashes #

Redict hashes are record types structured as collections of field-value pairs. You can use hashes to represent basic objects and to store groupings of counters, among other things.

> HSET bike:1 model Deimos brand Ergonom type 'Enduro bikes' price 4972
(integer) 4
> HGET bike:1 model
"Deimos"
> HGET bike:1 price
"4972"
> HGETALL bike:1
1) "model"
2) "Deimos"
3) "brand"
4) "Ergonom"
5) "type"
6) "Enduro bikes"
7) "price"
8) "4972"

While hashes are handy to represent objects, actually the number of fields you can put inside a hash has no practical limits (other than available memory), so you can use hashes in many different ways inside your application.

HDEL

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

HELLO

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

HEXISTS

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

HGET

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

HGETALL

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

HINCRBY

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

HINCRBYFLOAT

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

HKEYS

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

HLEN

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

HMGET

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

HMSET

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

HRANDFIELD

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

HSCAN

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

HSET

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

HSETNX

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

HSTRLEN

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

HVALS

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

Redict HyperLogLog

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

Introduction to Redict HyperLogLogs #

HyperLogLog is a probabilistic data structure that estimates the cardinality of a set. As a probabilistic data structure, HyperLogLog trades perfect accuracy for efficient space utilization.

The Redict HyperLogLog implementation uses up to 12 KB and provides a standard error of 0.81%.

Counting unique items usually requires an amount of memory proportional to the number of items you want to count, because you need to remember the elements you have already seen in the past in order to avoid counting them multiple times. However, a set of algorithms exist that trade memory for precision: they return an estimated measure with a standard error, which, in the case of the Redict implementation for HyperLogLog, is less than 1%. The magic of this algorithm is that you no longer need to use an amount of memory proportional to the number of items counted, and instead can use a constant amount of memory; 12k bytes in the worst case, or a lot less if your HyperLogLog (We’ll just call them HLL from now) has seen very few elements.

INCR

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

INCRBY

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

INCRBYFLOAT

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

INFO

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

Key Eviction

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

Overview of Redict key eviction policies #

When Redict is used as a cache, it is often convenient to let it automatically evict old data as you add new data. This behavior is well known in the developer community, since it is the default behavior for the popular memcached system.

This page covers the more general topic of the Redict maxmemory directive used to limit the memory usage to a fixed amount. It also extensively covers the LRU eviction algorithm used by Redict, which is actually an approximation of the exact LRU.

KEYS

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

Managing Keys in Redict

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

Managing Keys in Redict #

Redict keys are binary safe; this means that you can use any binary sequence as a key, from a string like “foo” to the content of a JPEG file. The empty string is also a valid key.

A few other rules about keys:

Very long keys are not a good idea. For instance a key of 1024 bytes is a bad idea not only memory-wise, but also because the lookup of the key in the dataset may require several costly key-comparisons. Even when the task at hand is to match the existence of a large value, hashing it (for example with SHA1) is a better idea, especially from the perspective of memory and bandwidth.
Very short keys are often not a good idea. There is little point in writing “u1000flw” as a key if you can instead write “user:1000:followers”. The latter is more readable and the added space is minor compared to the space used by the key object itself and the value object. While short keys will obviously consume a bit less memory, your job is to find the right balance.
Try to stick with a schema. For instance “object-type:id” is a good idea, as in “user:1000”. Dots or dashes are often used for multi-word fields, as in “comment:4321:reply.to” or “comment:4321:reply-to”.
The maximum allowed key size is 512 MB.

Altering and querying the key space #

There are commands that are not defined on particular types, but are useful in order to interact with the space of keys, and thus, can be used with keys of any type.

Redict keyspace notifications

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

Monitor changes to Redict keys and values in real time #

Keyspace notifications allow clients to subscribe to Pub/Sub channels in order to receive events affecting the Redict data set in some way.

Examples of events that can be received are:

All the commands affecting a given key.
All the keys receiving an LPUSH operation.
All the keys expiring in the database 0.

Note: Redict Pub/Sub is fire and forget that is, if your Pub/Sub client disconnects, and reconnects later, all the events delivered during the time the client was disconnected are lost.

LASTSAVE

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

LATENCY

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

Latency diagnosis

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

Diagnosing latency issues #

This document will help you understand what the problem could be if you are experiencing latency problems with Redict.

In this context latency is the maximum delay between the time a client issues a command and the time the reply to the command is received by the client. Usually Redict processing time is extremely low, in the sub microsecond range, but there are certain conditions leading to higher latency figures.

LATENCY DOCTOR

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

LATENCY GRAPH

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

LATENCY HELP

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

LATENCY HISTOGRAM

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

LATENCY HISTORY

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

LATENCY LATEST

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

Redict latency monitoring

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

Latency Monitoring #

Redict is often used for demanding use cases, where it serves a large number of queries per second per instance, but also has strict latency requirements for the average response time and the worst-case latency.

While Redict is an in-memory system, it deals with the operating system in different ways, for example, in the context of persisting to disk. Moreover Redict implements a rich set of commands. Certain commands are fast and run in constant or logarithmic time. Other commands are slower O(N) commands that can cause latency spikes.

LATENCY RESET

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

LCS

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

LINDEX

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

LINSERT

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

Redict lists

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

Introduction to Redict Lists #

Redict lists are linked lists of string values. Redict lists are frequently used to:

Implement stacks and queues.
Build queue management for background worker systems.

Basic commands #

LPUSH adds a new element to the head of a list; RPUSH adds to the tail.
LPOP removes and returns an element from the head of a list; RPOP does the same but from the tails of a list.
LLEN returns the length of a list.
LMOVE atomically moves elements from one list to another.
LTRIM reduces a list to the specified range of elements.

Blocking commands #

Lists support several blocking commands. For example:

LLEN

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

LMOVE

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

LMPOP

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

LOLWUT

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

LPOP

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

LPOS

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

LPUSH

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

LPUSHX

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

LRANGE

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

LREM

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

LSET

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

LTRIM

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

MEMORY

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

MEMORY DOCTOR

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

MEMORY HELP

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

MEMORY MALLOC-STATS

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

Memory optimization

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

Strategies for Optimizing Memory Usage in Redict #

Special encoding of small aggregate data types #

Many data types are optimized to use less space up to a certain size. Hashes, Lists, Sets composed of just integers, and Sorted Sets, when smaller than a given number of elements, and up to a maximum element size, are encoded in a very memory-efficient way that uses up to 10 times less memory (with 5 times less memory used being the average saving).

MEMORY PURGE

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

MEMORY STATS

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

MEMORY USAGE

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

MGET

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

Example: Microblogging

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

Example: Microblogging #

This article describes the design and implementation of a very simple Microblogging Platform written using PHP with Redict as the only database. The programming community has traditionally considered key-value stores as a special purpose database that couldn’t be used as a drop-in replacement for a relational database for the development of web applications. This article will try to show that Redict data structures on top of a key-value layer are an effective data model to implement many kinds of applications.

MIGRATE

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

Migrating Lua scripts

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

Migrating Lua scripts #

Redict is backwards-compatible with the Lua API used by Redis®¹ OSS 7.2.4, and all Lua scripts targetting this version of Redis® will work with Redict without changes.

If you wish to update your Lua scripts to remove references to Redis®, you may simply substitute the “redis” global for “redict”, for instance by changing “redis.call” to “redict.call”.

Warning: Changing “redis” to “redict” in your Lua scripts will change the SHA-1 checksum of your script, which in turn will affect the hash you use with the EVALSHA and EVALSHA_RO commands.

Migrating Redis® Modules

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

Migrating Redis® Modules to the Redict API #

Redict is binary compatible with Redis® Modules targetting Redis® OSS versions 7.2.4 and earlier. Modules built against redismodule.h may be loaded as a shared object via the loadmodule config option and --loadmodule command-line argument to redict-server in the same manner with which they are used with redis-server, without changes to the module source code.

If you are the maintainer of a Redis® Module and wish to migrate your module to target the Redict API instead, the following changes are required:

Migrating to hiredict

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

Compatibility with Hiredis #

Hiredict includes shim headers, that define the old symbols as the new ones, and also a shim pkg-config file adjusted to include shims and link with hiredict.

Build systems utilizing pkg-config need just rebuild to link against hiredict, the shim will make sure the right symbols are used.

Build systems that manually look for hiredis, may need to change the library name, as we don’t provide libhiredis, so calls to find_library need to be adjusted to look for hiredict instead.

MODULE

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

MODULE HELP

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

MODULE LIST

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

MODULE LOAD

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

MODULE LOADEX

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

MODULE UNLOAD

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

MONITOR

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

MOVE

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

MSET

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

MSETNX

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

MULTI

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

OBJECT

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

OBJECT ENCODING

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

OBJECT FREQ

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

OBJECT HELP

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

OBJECT IDLETIME

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

OBJECT REFCOUNT

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

PERSIST

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

Redict persistence

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

How Redict Writes Data to Disk #

Persistence refers to the writing of data to durable storage, such as a solid-state disk (SSD). Redict provides a range of persistence options. These include:

RDB (Redict Database): RDB persistence performs point-in-time snapshots of your dataset at specified intervals.
AOF (Append Only File): AOF persistence logs every write operation received by the server. These operations can then be replayed again at server startup, reconstructing the original dataset. Commands are logged using the same format as the Redict protocol itself.
No persistence: You can disable persistence completely. This is sometimes used when caching.
RDB + AOF: You can also combine both AOF and RDB in the same instance.

To learn more about how to evaluate your Redict persistence strategy, read on.

PEXPIRE

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

PEXPIREAT

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

PEXPIRETIME

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

PFADD

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

PFCOUNT

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

PFDEBUG

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

PFMERGE

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

PFSELFTEST

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

PING

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

Redict Pipelining

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

Redict Pipelining #

Redict pipelining is a technique for improving performance by issuing multiple commands at once without waiting for the response to each individual command. Pipelining is supported by most Redict clients. This document describes the problem that pipelining is designed to solve and how pipelining works in Redict.

Request/Response protocols and round-trip time (RTT) #

Redict is a TCP server using the client-server model and what is called a Request/Response protocol.

PSETEX

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

PSUBSCRIBE

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

PSYNC

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

PTTL

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

Redict Pub/Sub

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

How to Use Pub/Sub Channels in Redict #

SUBSCRIBE, UNSUBSCRIBE and PUBLISH implement the Publish/Subscribe messaging paradigm where (citing Wikipedia) senders (publishers) are not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into channels, without knowledge of what (if any) subscribers there may be. Subscribers express interest in one or more channels and only receive messages that are of interest, without knowledge of what (if any) publishers there are. This decoupling of publishers and subscribers allows for greater scalability and a more dynamic network topology.

PUBLISH

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

PUBSUB

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

PUBSUB CHANNELS

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

PUBSUB HELP

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

PUBSUB NUMPAT

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

PUBSUB NUMSUB

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

PUBSUB SHARDCHANNELS

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

PUBSUB SHARDNUMSUB

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

PUNSUBSCRIBE

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

QUIT

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

RANDOMKEY

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

READONLY

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

READWRITE

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

RENAME

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

RENAMENX

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

REPLCONF

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

REPLICAOF

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

Redict replication

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

How Redict supports high availability and failover with replication #

At the base of Redict replication (excluding the high availability features provided as an additional layer by Redict Cluster or Redict Sentinel) there is a leader follower (master-replica) replication that is simple to use and configure. It allows replica Redict instances to be exact copies of master instances. The replica will automatically reconnect to the master every time the link breaks, and will attempt to be an exact copy of it regardless of what happens to the master.

RESET

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

RESTORE

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

RESTORE-ASKING

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

ROLE

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

RPOP

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

RPOPLPUSH

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

RPUSH

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

RPUSHX

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

SADD

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

SAVE

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

SCAN

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

SCARD

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

SCRIPT

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

SCRIPT DEBUG

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

SCRIPT EXISTS

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

SCRIPT FLUSH

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

SCRIPT HELP

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

SCRIPT KILL

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

SCRIPT LOAD

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

SDIFF

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

SDIFFSTORE

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

SELECT

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

High availability with Redict Sentinel

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

Redict Sentinel provides high availability for Redict when not using Redict Cluster.

Redict Sentinel also provides other collateral tasks such as monitoring, notifications and acts as a configuration provider for clients.

This is the full list of Sentinel capabilities at a macroscopic level (i.e. the big picture):

Monitoring. Sentinel constantly checks if your master and replica instances are working as expected.
Notification. Sentinel can notify the system administrator, or other computer programs, via an API, that something is wrong with one of the monitored Redict instances.
Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a replica is promoted to master, the other additional replicas are reconfigured to use the new master, and the applications using the Redict server are informed about the new address to use when connecting.
Configuration provider. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redict master responsible for a given service. If a failover occurs, Sentinels will report the new address.

Sentinel as a distributed system #

Redict Sentinel is a distributed system:

Sentinel client spec

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

How to build clients for Redict Sentinel #

Redict Sentinel is a monitoring solution for Redict instances that handles automatic failover of Redict 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 Redict masters or replicas, clients are required to have explicit support for Redict Sentinel.

SET

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

SETBIT

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

SETEX

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

SETNX

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

SETRANGE

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

Redict sets

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

Introduction to Redict Sets #

A Redict set is an unordered collection of unique strings (members). You can use Redict sets to efficiently:

Track unique items (e.g., track all unique IP addresses accessing a given blog post).
Represent relations (e.g., the set of all users with a given role).
Perform common set operations such as intersection, unions, and differences.

Basic commands #

SADD adds a new member to a set.
SREM removes the specified member from the set.
SISMEMBER tests a string for set membership.
SINTER returns the set of members that two or more sets have in common (i.e., the intersection).
SCARD returns the size (a.k.a. cardinality) of a set.

See the complete list of set commands.

Setup Tips

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

Redict Setup Tips #

Linux #

Deploy Redict using the Linux operating system. Redict is also tested on OS X, and from time to time on FreeBSD and OpenBSD systems. However, Linux is where most of the stress testing is performed, and where most production deployments are run.
Set the Linux kernel overcommit memory setting to 1. Add vm.overcommit_memory = 1 to /etc/sysctl.conf. Then, reboot or run the command sysctl vm.overcommit_memory=1 to activate the setting. See FAQ: Background saving fails with a fork() error on Linux? for details.
To ensure the Linux kernel feature Transparent Huge Pages does not impact Redict memory usage and latency, run the command: echo never > /sys/kernel/mm/transparent_hugepage/enabled to disable it. See Latency Diagnosis - Latency induced by transparent huge pages for additional context.

Memory #

Ensured that swap is enabled and that your swap file size is equal to amount of memory on your system. If Linux does not have swap set up, and your Redict instance accidentally consumes too much memory, Redict can crash when it is out of memory, or the Linux kernel OOM killer can kill the Redict process. When swapping is enabled, you can detect latency spikes and act on them.
Set an explicit maxmemory option limit in your instance to make sure that it will report errors instead of failing when the system memory limit is near to be reached. Note that maxmemory should be set by calculating the overhead for Redict, other than data, and the fragmentation overhead. So if you think you have 10 GB of free memory, set it to 8 or 9.
If you are using Redict in a write-heavy application, while saving an RDB file on disk or rewriting the AOF log, Redict can use up to 2 times the memory normally used. The additional memory used is proportional to the number of memory pages modified by writes during the saving process, so it is often proportional to the number of keys (or aggregate types items) touched during this time. Make sure to size your memory accordingly.
See the LATENCY DOCTOR and MEMORY DOCTOR commands to assist in troubleshooting.

Imaging #

When running under daemontools, use daemonize no.

Replication #

Set up a non-trivial replication backlog in proportion to the amount of memory Redict is using. The backlog allows replicas to sync with the primary (master) instance much more easily.
If you use replication, Redict performs RDB saves even if persistence is disabled. (This does not apply to diskless replication.) If you don’t have disk usage on the master, enable diskless replication.
If you are using replication, ensure that either your master has persistence enabled, or that it does not automatically restart on crashes. Replicas will try to maintain an exact copy of the master, so if a master restarts with an empty data set, replicas will be wiped as well.

Security #

By default, Redict does not require any authentication and listens to all the network interfaces. This is a big security issue if you leave Redict exposed on the internet or other places where attackers can reach it. See for example this attack to see how dangerous it can be. Please check our security page for information about how to secure Redict.

Running Redict on EC2 #

Use HVM based instances, not PV based instances.
Do not use old instance families. For example, use m3.medium with HVM instead of m1.medium with PV.
The use of Redict persistence with EC2 EBS volumes needs to be handled with care because sometimes EBS volumes have high latency characteristics.
You may want to try the new diskless replication if you have issues when replicas are synchronizing with the master.

Upgrading or restarting a Redict instance without downtime #

Redict is designed to be a long-running process in your server. You can modify many configuration options without a restart using the CONFIG SET command. You can also switch from AOF to RDB snapshots persistence, or the other way around, without restarting Redict. Check the output of the CONFIG GET * command for more information.

SHUTDOWN

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

Redict signal handling

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

How Redict Handles Common Unix Signals #

This document provides information about how Redict reacts to different POSIX signals such as SIGTERM and SIGSEGV.

SIGTERM and SIGINT #

The SIGTERM and SIGINT signals tell Redict to shut down gracefully. When the server receives this signal, it does not immediately exit. Instead, it schedules a shutdown similar to the one performed by the SHUTDOWN command. The scheduled shutdown starts as soon as possible, specifically as long as the current command in execution terminates (if any), with a possible additional delay of 0.1 seconds or less.

SINTER

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

SINTERCARD

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

SINTERSTORE

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

SISMEMBER

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

SLAVEOF

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

SLOWLOG

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

SLOWLOG GET

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

SLOWLOG HELP

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

SLOWLOG LEN

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

SLOWLOG RESET

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

SMEMBERS

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

SMISMEMBER

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

SMOVE

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

SORT

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

SORT_RO

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

Redict sorted sets

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

Introduction to Redict Sorted Sets #

A Redict sorted set is a collection of unique strings (members) ordered by an associated score. When more than one string has the same score, the strings are ordered lexicographically. Some use cases for sorted sets include:

Leaderboards. For example, you can use sorted sets to easily maintain ordered lists of the highest scores in a massive online game.
Rate limiters. In particular, you can use a sorted set to build a sliding-window rate limiter to prevent excessive API requests.

You can think of sorted sets as a mix between a Set and a Hash. Like sets, sorted sets are composed of unique, non-repeating string elements, so in some sense a sorted set is a set as well.

SPOP

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

SPUBLISH

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

SRANDMEMBER

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

SREM

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

SSCAN

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

SSUBSCRIBE

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

Redict Streams

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

Introduction to Redict Streams #

A Redict stream is a data structure that acts like an append-only log but also implements several operations to overcome some of the limits of a typical append-only log. These include random access in O(1) time and complex consumption strategies, such as consumer groups. You can use streams to record and simultaneously syndicate events in real time. Examples of Redict stream use cases include:

Redict Strings

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

Introduction to Redict Strings #

Redict strings store sequences of bytes, including text, serialized objects, and binary arrays. As such, strings are the simplest type of value you can associate with a Redict key. They’re often used for caching, but they support additional functionality that lets you implement counters and perform bitwise operations, too.

Since Redict keys are strings, when we use the string type as a value too, we are mapping a string to another string. The string data type is useful for a number of use cases, like caching HTML fragments or pages.

STRLEN

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

SUBSTR

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

SUNION

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

SUNIONSTORE

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

SUNSUBSCRIBE

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

SWAPDB

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

SYNC

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

TIME

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

TLS

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

Redict TLS Support #

SSL/TLS is supported by Redict as an optional feature that needs to be enabled at compile time.

Getting Started #

Building #

To build with TLS support you’ll need OpenSSL development libraries (e.g. libssl-dev on Debian/Ubuntu).

Build Redict with the following command:

make BUILD_TLS=yes

Tests #

To run Redict test suite with TLS, you’ll need TLS support for TCL (i.e. tcl-tls package on Debian/Ubuntu).

TOUCH

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

Redict Transactions

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

How Transactions Work in Redict #

Redict Transactions allow the execution of a group of commands in a single step, they are centered around the commands MULTI, EXEC, DISCARD and WATCH. Redict Transactions make two important guarantees:

All the commands in a transaction are serialized and executed sequentially. A request sent by another client will never be served in the middle of the execution of a Redict Transaction. This guarantees that the commands are executed as a single isolated operation.

Troubleshooting Redict

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

Troubleshooting #

This page tries to help you with what to do if you have issues with Redict. Part of the Redict project is helping people that are experiencing problems because we don’t like to leave people alone with their issues.

If you have latency problems with Redict, that in some way appears to be idle for some time, read our Redis latency troubleshooting guide.
Redis stable releases are usually very reliable, however in the rare event you are experiencing crashes the developers can help a lot more if you provide debugging information. Please read our Debugging Redis guide.
We have a long history of users experiencing crashes with Redis that actually turned out to be servers with broken RAM. Please test your RAM using redict-server –test-memory in case Redis is not stable in your system. Redis built-in memory test is fast and reasonably reliable, but if you can you should reboot your server and use memtest86.

For every other problem please drop a message in our Chat. See Community resources for details.

TTL

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

TYPE

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

UNLINK

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

UNSUBSCRIBE

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

UNWATCH

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

Usage with containers

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

Redict containers #

We provide official containers for Redict from our container registry at registry.redict.io. The source code for our container images is available on Codeberg.

Quickstart #

To start a Redict server:

$ docker run --name redict -d -p 6379:6379 registry.redict.io/redict

This will start a Redict server running on the default port on your local system. To interact with the running server with the redict-cli tool:

$ docker exec -it redict /bin/redict-cli

Available containers #

The default redict (and redict:latest) containers are scratch containers which only contain the Redict executables and the supporting files necessary to run them. If you need a more complete container, with a shell and other supporting tools, choose Alpine or Debian as your base.

WAIT

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

WAITAOF

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

WATCH

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

XACK

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

XADD

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

XAUTOCLAIM

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

XCLAIM

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

XDEL

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

XGROUP

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

XGROUP CREATE

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

XGROUP CREATECONSUMER

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

XGROUP DELCONSUMER

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

XGROUP DESTROY

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

XGROUP HELP

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

XGROUP SETID

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

XINFO

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

XINFO CONSUMERS

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

XINFO GROUPS

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

XINFO HELP

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

XINFO STREAM

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

XLEN

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

XPENDING

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

XRANGE

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

XREAD

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

XREADGROUP

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

XREVRANGE

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

XSETID

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

XTRIM

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

ZADD

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

ZCARD

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

ZCOUNT

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

ZDIFF

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

ZDIFFSTORE

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

ZINCRBY

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

ZINTER

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

ZINTERCARD

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

ZINTERSTORE

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

ZLEXCOUNT

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

ZMPOP

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

ZMSCORE

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

ZPOPMAX

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

ZPOPMIN

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

ZRANDMEMBER

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

ZRANGE

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

ZRANGEBYLEX

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

ZRANGEBYSCORE

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

ZRANGESTORE

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

ZRANK

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

ZREM

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

ZREMRANGEBYLEX

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

ZREMRANGEBYRANK

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

ZREMRANGEBYSCORE

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

ZREVRANGE

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

ZREVRANGEBYLEX

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

ZREVRANGEBYSCORE

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

ZREVRANK

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

ZSCAN

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

ZSCORE

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

ZUNION

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

ZUNIONSTORE

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

Redict

Redis benchmark

Community Redict modules

Community Modules for Redict #

Executing Lua scripts

Executing Lua scripts in Redict #

Migrating packages

Migrating your distribution to Redict #

Build system changes #

Redict modules and blocking commands

Redict modules and blocking commands #

Migrating containers

Migrating to Redict containers #

Modules API for native types

Modules API for native types #

Using Lua functions

Redict Functions #

Debugging Lua scripts

Debugging Lua scripts in Redict #

API reference

Redict Lua API reference #

Sandbox context #

Community resources

Engaging with the community #

Repository and issue tracker #

About the license

About the license #

Redict 7.3.6 is now available

Redict 7.3.5 is now available

Redict 7.3.4 is now available

Redict 7.3.3 is now available for urgent deployment

Redict 7.3.2 is now available for urgent deployment

Redict 7.3.1 is now available for urgent deployment

Early notice for Redict 7.3.1 security release

Redict 7.3.0 is now available

Redict release candidate 7.3.0-rc1 is now available: call for testing

Redict is an independent, copyleft fork of Redis®

ACL

ACL

Redict Access Control List #

ACL CAT

ACL DELUSER

ACL DRYRUN

ACL GENPASS

ACL GETUSER

ACL HELP

ACL LIST

ACL LOAD

ACL LOG

ACL SAVE

ACL SETUSER

ACL USERS

ACL WHOAMI

API reference

Modules API reference #

Heap allocation raw functions #

RedictModule_Alloc #

APPEND

ASKING

AUTH

BGREWRITEAOF

BGSAVE

BITCOUNT

BITFIELD

BITFIELD_RO

Redict bitfields

Introduction to Redict Bitfields #

Basic commands #

Example #

Redict bitmaps

Introduction to Redict Bitmaps #

BITOP

BITPOS

BLMOVE

BLMPOP

BLPOP

BRPOP

BRPOPLPUSH

Bulk Loading

Writing Data in Bulk Using the Redict Protocol #

`RedictModule_Alloc` #