Redis

OBJECT ENCODING reports the internal memory layout Redis chose for that value. Small collections use a compact, cache-friendly flat array (listpack/intset) that saves a lot of memory; once they grow past configured thresholds Redis switches to a real hash table or skiplist for O(1)/O(log n) access.

HSET user:42 name Ada email [email protected] writes fields; HGET reads one, HMGET reads several in one call, HGETALL returns every field and value. HDEL removes fields, and when the last field goes the key itself is deleted — Redis has no empty hashes.

An ordered sequence of strings with fast ends. LPUSH/RPUSH add at head/tail, LPOP/RPOP remove there, all O(1). LRANGE reads a slice; LINDEX/LSET/LINSERT/LREM touch the middle and are O(N) because Redis walks the list. Duplicates are allowed, order is insertion order, and an emptied list key is deleted.

A Set is an unordered collection of unique strings. SADD adds (duplicates are silently ignored), SREM removes, SISMEMBER tests membership, SCARD returns the size, SMEMBERS returns everything. Add, remove, membership test and count are all O(1).

A Sorted Set holds unique string members, each with a floating-point score, kept ordered by score ascending and by member bytes when scores tie. ZADD adds or updates, ZSCORE reads a score, ZRANK gives the 0-based position, ZRANGE reads a slice, ZCARD counts.

Read with GET. Hit: return the cached value. Miss (nil): load from the system of record, serialize it, write it back with a single SET key value EX <ttl>, and return it. Readers fill the cache lazily; a miss is normal, not an error.

Deleting is the safest default: the next reader reloads from the database. Overwriting with a fresh TTL restarts the clock, so a hot key's expiry never fires and a wrong value can live forever. Overwriting while keeping the remaining TTL keeps a hard age bound.

Delete the cached key rather than overwriting it, and delete only after the database transaction commits. Deletion is idempotent, so racing writers cannot leave a wrong value stuck until the TTL expires. The cost is one extra miss.

A hot key is one key taking a hugely disproportionate share of traffic. Because a key's name determines exactly one shard, and that shard executes commands on one thread, the load cannot be spread by adding nodes — one key saturates one CPU core and one network link.

When a popular key expires, every concurrent request gets nil from GET and all of them recompute the same value against the database at once. The number of duplicate recomputes is roughly request rate times recompute latency, and the resulting slowdown makes the window longer.

The AOF is a log of every write command that changed the dataset, appended after the command runs; recovery replays the commands. A snapshot only stores state as of the moment it was taken, so a crash loses everything since it — the AOF narrows that loss to a second or less.

SAVE writes the snapshot on the main thread, so the server answers no commands until it finishes — unusable in production. BGSAVE forks a child that writes the snapshot while the parent keeps serving; only the brief fork itself pauses the server.

always fsyncs before replying, so an acknowledged write survives a crash, at a big throughput cost. everysec (the default) fsyncs once per second in a background thread, risking about a second of writes. no never fsyncs — the OS flushes when it likes, so a machine crash can lose tens of seconds.

The AOF records every write, so it grows with write volume and repeats history. BGREWRITEAOF forks a child that writes a new minimal file reproducing the current in-memory dataset, then atomically swaps it in: smaller file, faster restart.

With it on, a rewritten append-only file starts with the whole dataset in compact binary snapshot format, then appends later write commands as normal text. One file, snapshot body plus command tail. You gain much faster loading and a smaller file; durability is unchanged.

XRANGE is a history query: give it a start and end ID and it returns that slice in order, always immediately. XREAD is a consumer: you give it the last ID you saw and it returns only newer entries, and with BLOCK it waits for entries that have not arrived yet.

Fire-and-forget, at-most-once. PUBLISH hands the message only to clients subscribed at that instant and stores nothing. A subscriber that is disconnected, still reconnecting, or killed for a full output buffer misses those messages permanently: no replay, no offsets, no acknowledgement.

Redis generates an ID of the form milliseconds-sequence, e.g. 1699999999999-0. The first part is the server's Unix time in milliseconds, the second a counter that increments for additional entries within the same millisecond. IDs are strictly increasing, so XADD rejects any ID not greater than the stream's last one.

Create the group once: XGROUP CREATE key group $ (use 0 to replay history, MKSTREAM if the stream may not exist). Each worker reads with XREADGROUP GROUP group consumer-name STREAMS key >. The > means entries never yet delivered to anyone in this group, so Redis gives each new entry to one consumer only.

The entry goes into the group's Pending Entries List (PEL): entry ID, owning consumer, last delivery time and delivery count. XACK key group id removes it from the PEL. Inspect with XPENDING (summary) or XPENDING key group IDLE ms start end count (per-entry detail).

Redis Cluster computes CRC16 of the key modulo 16384, giving a hash slot. Each of the 16384 slots is owned by exactly one master node, so the slot decides the node. Keys are never hashed against node addresses.

REPLICAOF host port makes the instance a replica: it discards its own dataset, copies the primary's, and then applies the primary's write stream. It serves reads but rejects writes (replica-read-only is on by default). REPLICAOF NO ONE detaches it into an independent primary, keeping the data it has.

Nodes ping each other over the cluster bus and gossip what they see. A node unreachable for longer than cluster-node-timeout is flagged PFAIL (possibly failed); once a majority of primaries report PFAIL for it, one marks it FAIL and broadcasts that, which triggers replica election.

Curly braces form a hash tag: Redis hashes only the substring inside the first {...} instead of the whole key. Keys sharing a tag share a slot and therefore a node, which is how you co-locate keys that must be read or written together.

In cluster mode every key of a single command must live in one hash slot, because one node executes it locally with no cross-node coordination. Fix it by hash-tagging the keys into one slot, by issuing separate GETs pipelined per node, or by restructuring the data into one key.

The cost is 10,000 network round trips, not Redis work. Pipelining means writing many commands to the socket without waiting for each reply, then reading the replies in order. Same server work, far fewer round trips, often 5-50x faster.

Redis needs to know which keys a script touches before running it, so it can route the command to the right cluster node, enforce ACL key permissions and cross-slot rules. Keys go in KEYS via the numkeys count; everything else goes in ARGV.

MULTI puts the connection in transaction mode; each following command is only queued and answers +QUEUED, not executed. EXEC runs the whole queue in order with no other client's commands interleaved, returning an array of replies, one per queued command. DISCARD throws the queue away and leaves transaction mode.

Yes, other clients can run in between. A pipeline only guarantees that your commands execute in the order you sent them on that connection, and that replies come back in that order. It gives no atomicity, no isolation, and no all-or-nothing behaviour on failure.

A Function library is named Lua code loaded once with FUNCTION LOAD and stored in the dataset itself — persisted to RDB/AOF, replicated, surviving restart. You invoke it by name with FCALL. EVAL scripts are anonymous, cached only, and identified by SHA1.

No. Redis frees an expired key only when a command touches it (lazy delete) or when a background sampling cycle picks it. Reads never return an expired value, but the memory can stay allocated for a while.

TTL returns the remaining seconds, -1 if the key exists with no expiry, and -2 if the key does not exist. PTTL is the same in milliseconds. PERSIST key removes the expiry and keeps the value, returning 1 if an expiry was removed, 0 otherwise.

Redis keeps no global LRU list. When memory exceeds maxmemory it picks maxmemory-samples random keys (default 5), reads the last-access timestamp stored in each key's object header, and evicts the idlest. More samples means better accuracy and more CPU.

Set notify-keyspace-events to a string of flags; empty means off. You must include K (keyspace channels) and/or E (keyevent channels) plus at least one event class such as g generic, $ string, l list, x expired, e evicted, or A for all classes. Example: Ex.

It repeatedly samples about 20 random keys from the table of keys with a TTL, deletes the expired ones, and loops again if more than 25% of the sample was expired. Time-boxed per run, so it bounds stale keys statistically, not exactly.

Command execution is single-threaded: one command at a time runs on the main event loop, so every command is atomic and no locks are needed. The cost is that one slow command stalls all clients, and one instance uses about one CPU core.

KEYS visits every key in the database in a single command, O(N), and Redis executes commands one at a time — so every other client waits until it finishes, potentially seconds. Use SCAN, which iterates the same keyspace in small cursor-based batches.

DEL frees every element on the main thread, so removing a huge collection blocks all clients. UNLINK removes the key from the keyspace immediately and hands the expensive free to a background lazyfree thread. The lazyfree-lazy-* settings apply the same behaviour automatically to eviction, expiry and overwrites.

SLOWLOG stores the last N commands whose execution exceeded slowlog-log-slower-than microseconds. Read with SLOWLOG GET/LEN, clear with SLOWLOG RESET. It times only command execution inside the server — not network transfer, not time spent waiting in the queue behind other commands.

A client sends every command as a RESP array of bulk strings; the server replies with one typed frame. RESP2 has five types identified by a first byte: + simple string, - error, : integer, $ bulk string (length-prefixed, binary safe), * array. Every frame ends with CRLF.