Architecture, Keyspace & Eviction

Redis clients speak RESP (the Redis Serialization Protocol). A connection starts in RESP2 by default; sending HELLO 3 switches it to RESP3 for the rest of that connection. RESP3 adds native map, set and double/boolean types (so a client library can hand back a proper map instead of a flat array of alternating keys and values), and, more importantly, a push type: a message the server sends unprompted, not as the reply to a request. Pub/sub messages, MONITOR output, and client-side caching invalidation messages all arrive as RESP3 push frames when the connection has negotiated RESP3. A client that stays on RESP2 still receives the same information, just multiplexed as ordinary replies/pushes in the older wire format.

See Redis serialization protocol specification for the full RESP2/RESP3 wire format and HELLO for the handshake itself.

A handful of server-side settings bound how much work a connected client can impose before Redis protects itself:

Because the command executor is single-threaded, a command that takes a long time to run — a large KEYS *, an unbounded SORT, a poorly-written Lua script, an O(N) command over a huge collection — blocks every other client for its whole duration; there is no other thread to serve them from meanwhile. Blocking commands such as BLPOP/BRPOP/XREAD BLOCK are a deliberate exception: they suspend the *calling* client without occupying the executor while waiting, so other clients keep being served normally. For scripts and transactions, busy-reply-threshold (the renamed lua-time-limit) sets how many milliseconds a script may run before Redis starts replying BUSY to most other commands, which is a diagnostic signal rather than a way to actually stop the running script — only SCRIPT KILL (harmless for a read-only script) or SHUTDOWN NOSAVE recovers a genuinely stuck one.

See Client information and Redis configuration for the full set of client-handling directives.

A single Redis server (outside Cluster mode) exposes 16 numbered logical databases by default, selected with SELECT <index> on a connection; keys in one are invisible to commands run against another, and MOVE shifts a key from one to another. SELECT is a per-connection state, so a connection pool must not assume every borrowed connection is still on the database it last selected. Redis Cluster only ever has database 0 — multi-database SELECT is not supported across a cluster, because keys are distributed across shards by hash slot and a second logical database per node would not compose with that sharding. Applications that need Cluster and also want dataset isolation reach for separate key prefixes (as the Bookshop scheme does) or separate Redis deployments instead of SELECT.

OBJECT ENCODING key reports the concrete internal representation Redis chose for a value — for example a small hash stored as listpack versus a large one promoted to hashtable, or a small sorted set as listpack versus skiplist — which is useful when a value is using more memory or behaving with different complexity than expected, since the encoding (not just the declared type) determines both.

Listing keys in a running Redis instance is done with SCAN, not KEYS. KEYS pattern walks the entire keyspace in one call and returns every match at once; on the single command-executing thread described above, that means every other client is blocked for however long the scan and the (potentially huge) reply take to build, which on a keyspace of any real size turns a debugging command into a self-inflicted outage. SCAN cursor [MATCH pattern] [COUNT count] [TYPE type] walks the same keyspace incrementally instead: each call returns a cursor and a small batch of keys, so the work is spread across many round trips and never holds the executor for longer than one small batch. MATCH filters by glob pattern (evaluated after fetching a batch, not before, so COUNT still bounds the underlying work rather than the number of matches returned), and TYPE restricts the scan to one data type. SCAN is also safe to run against a live, mutating keyspace: it guarantees every key present for the whole scan is returned at least once, though a key added or removed during the scan may or may not appear.

See SCAN, OBJECT ENCODING, and UNLINK for the full command references.

allkeys-lrm/volatile-lrm are new in Redis 8.6: LRM (Least Recently Modified) tracks write recency rather than access recency — commands such as SET, INCR, APPEND, SETRANGE and EXPIRE reset a key’s LRM timestamp, while read-only commands such as GET, STRLEN, EXISTS, TTL, TYPE and GETRANGE do not. That makes LRM a fit for a read-heavy workload where you want to keep frequently read data around and evict data that has gone stale from a write standpoint, regardless of how often it is still being read — something plain LRU cannot express, since LRU treats a read as refreshing recency too. Every volatile-* policy behaves like noeviction once no key in the dataset carries a TTL, since there is then nothing in its candidate set to evict.

Redis does not track true least-recently-used/modified order (that would need a full ordered structure kept in sync on every access). Instead, on each eviction it samples a small number of random keys and evicts the best candidate found in that sample — an approximation close to true LRU/LRM in practice, tunable with:

Raising maxmemory-samples trades a little CPU for a closer approximation to the true policy; the default of 5 is a reasonable middle ground for most workloads.

LFU counters are approximated similarly, via a probabilistic Morris counter per key plus a decay period, and are tunable with two directives from redis.conf:

OBJECT FREQ key returns a key’s current approximated LFU counter (only meaningful when an LFU policy is active), and OBJECT IDLETIME key returns seconds since a key was last accessed (only meaningful under an LRU/noeviction/random policy, since an LFU policy does not track idle time the same way).

redis-cli --hotkeys scans the keyspace using OBJECT FREQ to report the keys with the highest access frequency; it requires an LFU (allkeys-lfu/volatile-lfu) policy to be active, since that is what populates the counters it reads.

Separately, Redis 8.6 adds a HOTKEYS server command (HOTKEYS START/STOP/GET/RESET) that tracks hot keys directly on the server over a defined time window, ranking them by share of CPU time and network bytes rather than by the LFU counter redis-cli --hotkeys relies on — useful when the policy in effect is not LFU-based at all, or when CPU/bandwidth cost is what actually matters rather than raw access count.

For a cache — values that can always be recomputed or re-fetched from a system of record, such as bookshop:cache:book:<isbn> — allkeys-lru is the sensible default: it needs no TTL bookkeeping to be effective and adapts well to the Pareto-shaped access pattern most caches see, and allkeys-lfu is worth trying instead when a smaller set of keys is accessed disproportionately more often than recency alone would capture. For a Redis deployment used as a primary store alongside data you cannot regenerate, start from noeviction (Redis fails writes rather than silently discarding data once maxmemory is hit) or reach for a volatile-* policy on top of TTLs you set deliberately, so only data you have already marked disposable is ever a candidate for eviction.

See Key eviction for the full eviction-policy reference, including the LRU-approximation comparison graphs and the LRM section this summarises.