Reference · Glossary
Glossary
Canonical definitions for this course. When a term is defined here, lessons use it exactly this way.
Living documentGrows with each lesson
- event loop
- The single-threaded cycle at the heart of Redis: using the OS readiness API
(
epoll/kqueue), it watches many client sockets and services
ready ones one after another. What lets one thread handle tens of thousands of
connections.
— intro'd in lesson 0001
- single-threaded (command execution)
- Redis runs the execution of user commands on one thread — commands
are serialized into a single queue and run back-to-back, never in parallel. Refers to
command execution specifically, not the whole process.
— intro'd in lesson 0001
- atomicity (of a command)
- The property that a command runs to completion with no other command interleaving.
A free consequence of single-threaded execution — the reason a single Redis operation
needs no external lock.
— intro'd in lesson 0001
- head-of-line blocking
- Because there is one thread and one queue, a slow command at the front stalls every
client behind it. The root cause of most sudden Redis-wide latency spikes.
— intro'd in lesson 0001
- time complexity (as latency)
- A command's big-O, listed on every redis.io command page. On the shared single
thread it measures how long the command holds the one worker — i.e. the latency it
imposes on all clients, not just the caller.
— intro'd in lesson 0001
- threaded I/O
- An optional feature since Redis 6.0 that reads/parses requests and
writes replies across multiple threads. Command execution still runs on the single
main thread.
— intro'd in lesson 0001
- SCAN (vs KEYS)
- A cursor-based, O(1)-per-call iterator over the keyspace (with type variants
HSCAN/SSCAN/ZSCAN). The production-safe
alternative to the O(N), server-blocking KEYS.
— intro'd in lesson 0001
- UNLINK (vs DEL)
- Deletes a key but reclaims its memory in a background thread, so
freeing a large collection doesn't block command execution.
DEL frees
inline on the main thread.
— intro'd in lesson 0001
- hash (data type)
- A key holding a map of field → value. Field-level access (
HGET/HSET)
is O(1); reading the whole thing (HGETALL) is O(N). Model a record as a hash to
avoid read-modify-write of a whole JSON blob.
— intro'd in lesson 0002
- set (data type)
- An unordered collection of unique members. Membership (
SISMEMBER) and add
(SADD) are O(1); enumerating all members (SMEMBERS) is O(N). The
right answer to "have we seen X?".
— intro'd in lesson 0002
- sorted set (zset)
- A set whose members each carry a numeric score and are kept ordered by it.
ZADD/ZRANK are O(log N), ZRANGE is O(log N + M),
ZSCORE is O(1). The structure behind leaderboards, priority queues, and
time-ordered indexes.
— intro'd in lesson 0002
- big key
- A single key holding a very large collection. Dangerous because every O(N) command on it
monopolizes the single thread, and even
DEL is O(N). Fix with bounded
collections, *SCAN iteration, and UNLINK.
— intro'd in lesson 0002
- listpack (encoding)
- A compact, cache-friendly flat encoding Redis uses for small hashes/sorted sets/lists
(and
intset for small integer sets) below config thresholds. O(N) scans of a
listpack are trivially cheap; Redis auto-converts to hashtable/skiplist past the threshold.
Inspect with OBJECT ENCODING.
— intro'd in lesson 0002
- TTL (time-to-live)
- A per-key countdown you attach (
EXPIRE, SET … EX). After it
elapses the key is logically dead. TTL key returns seconds left, -1
(exists, no TTL), or -2 (no such key). Note: a bare SET discards an
existing TTL unless you pass KEEPTTL.
— intro'd in lesson 0003
- volatile vs persistent key
- A volatile key has a TTL set; a persistent key has none.
The distinction matters for eviction:
volatile-* policies only ever evict
volatile keys. PERSIST turns a volatile key persistent.
— intro'd in lesson 0003
- passive (lazy) expiration
- Redis deletes an expired key when a client next accesses it — the access sees it's
timed out, removes it, and returns nil. Makes expiry invisible to reads instantly, but can't
reclaim keys that are never touched again.
— intro'd in lesson 0003
- active expiration
- A periodic background loop that samples random keys with a TTL, deletes the expired
ones, and repeats if >25% of the sample was expired. Closes the passive gap — but only
approximately, so up to ~25% of expired keys may still occupy memory.
— intro'd in lesson 0003
- eviction
- Redis removing keys to stay under the
maxmemory ceiling — driven by
memory pressure, not time. Distinct from TTL expiry: eviction is global and
capacity-driven; TTL is per-key and time-driven.
— intro'd in lesson 0003
- maxmemory-policy
- The rule choosing what to evict under pressure. Candidate axis:
allkeys-* (any
key) vs volatile-* (only TTL'd keys). Selection axis: lru /
lfu / random / ttl. Default is noeviction
(writes error with OOM). LRU/LFU are approximated by sampling (maxmemory-samples).
— intro'd in lesson 0003
- cache-aside (lazy loading)
- The caching pattern where the application checks the cache first and, on a miss,
reads the source of truth, populates the cache (with a TTL), and returns. The cache holds
only requested data. Contrast read-through (the cache layer loads on a miss).
— intro'd in lesson 0004
- cache hit / miss
- A hit is a lookup the cache can serve; a miss is one it
can't, forcing a fetch from the backing store. Miss rate × backend cost is what a cache
exists to reduce.
— intro'd in lesson 0004
- cache stampede (thundering herd / dogpile)
- A cascading failure where a hot key expires and many concurrent requests miss at once, all
hitting the backend simultaneously to recompute the same value. Amplified when many keys
share a TTL and expire in lockstep.
— intro'd in lesson 0004
- TTL jitter
- Adding a small random spread to each key's TTL (
EX base + rand()) so keys don't
expire simultaneously. The cheapest, always-applicable stampede mitigation.
— intro'd in lesson 0004
- single-flight lock (mutex)
- Letting exactly one request rebuild a missed key while others wait or serve stale, using
SET lock token NX EX as an atomic lock. Release only your own token (Lua
compare-and-delete); across nodes, use Redlock.
— intro'd in lesson 0004
- probabilistic early recomputation (XFetch)
- Refreshing a key before it expires with a probability that rises as the TTL nears,
so one request rebuilds early and the herd never forms (Vattani et al., VLDB 2015).
— intro'd in lesson 0004
- stale-while-revalidate
- Serving the last-known (stale) value while a single background refresh runs, so no reader
blocks on the backend. Standardized for HTTP in RFC 5861; applicable to any cache.
— intro'd in lesson 0004
- RDB (snapshot)
- A compact binary point-in-time dump of the whole dataset, produced at intervals
(
save N M) or on demand (BGSAVE). Great for backups and fast
restarts; the trade-off is losing everything written since the last snapshot.
— intro'd in lesson 0005
- AOF (append-only file)
- A log of every write operation, replayed at startup to rebuild state. More durable than
RDB (lose ≤ ~1s with
everysec); grows over time, so it's periodically
compacted by an AOF rewrite.
— intro'd in lesson 0005
- fork() + copy-on-write (COW)
- How Redis persists without blocking: it forks a child process to do the disk I/O while the
parent keeps serving. Parent and child share memory pages read-only; only pages the parent
modifies during the save are copied — so snapshot memory overhead scales with write churn,
not dataset size. The
fork() itself can spike latency on big instances.
— intro'd in lesson 0005
- appendfsync
- The AOF durability dial:
always (fsync per write — safest, slowest),
everysec (once per second — default; lose ≤ ~1s), no (OS decides —
~30s window). Trades write speed against how much you can lose on a crash.
— intro'd in lesson 0005
- AOF rewrite (BGREWRITEAOF)
- Rewriting the append log down to the shortest command sequence that reproduces the current
dataset, via a forked child (same COW trick as
BGSAVE). Keeps the AOF from
growing without bound.
— intro'd in lesson 0005
- leader-follower replication (primary / replica)
- Redis's replication model: one writable primary and one or more read-only
replicas that hold exact copies. Replicas can cascade (replica-of-replica).
Writes go to the primary; reads can fan out to replicas.
— intro'd in lesson 0006
- asynchronous replication
- The default mode: the primary acknowledges a write to the client before replicas
confirm it, propagating in the background. Low latency, but a failover can lose an
acknowledged write — so Redis is not a strongly-consistent (CP) store.
— intro'd in lesson 0006
- replication ID + offset
- A primary's identity for its data version: an ID plus a byte offset that increments for
every byte of the replication stream. A replica presents its last ID+offset via
PSYNC to resume where it left off.
— intro'd in lesson 0006
- partial vs full resynchronization
- Partial: a reconnecting replica gets just the missed stream slice from the
primary's backlog buffer. Full: when the backlog can't
cover the gap, the primary does a
BGSAVE/RDB, streams it, then replays buffered
writes. Diskless replication streams the RDB over the socket.
— intro'd in lesson 0006
- WAIT
WAIT n timeout blocks until the connection's writes are acknowledged by ≥ n
replicas (or the timeout). Best-effort — it does not make Redis strongly consistent;
a failover can still lose an acknowledged write.
— intro'd in lesson 0006- min-replicas-to-write
- A safety setting: the primary refuses writes unless at least N replicas are connected with
lag under
min-replicas-max-lag seconds. Bounds — but does not eliminate — the
data-loss window.
— intro'd in lesson 0006
- Sentinel
- A distributed companion system (run an odd number ≥ 3) that provides high availability for a
single primary: monitoring, notification, automatic failover, and client
service discovery ("who is the primary now?").
— intro'd in lesson 0007
- SDOWN vs ODOWN
- Subjectively down: one Sentinel privately suspects the primary (missed
PINGs). Objectively down: reached when ≥
quorum Sentinels agree
— the trigger to consider a failover.
— intro'd in lesson 0007
- quorum vs majority (Sentinel)
- Two separate gates: the quorum only detects failure (marks ODOWN);
actually performing the failover requires a Sentinel elected leader by a majority
of all Sentinels. This split stops a minority partition from promoting a primary.
— intro'd in lesson 0007
- hash slot
- One of Redis Cluster's 16384 partitions of the keyspace;
HASH_SLOT = CRC16(key) mod 16384. Each primary owns a subset; resharding moves
slots between nodes with no downtime.
— intro'd in lesson 0007
- MOVED vs ASK
- Cluster client redirections. MOVED: the slot permanently lives elsewhere →
update the slot map and retry there. ASK: the slot is migrating → send
ASKING and retry only this one query, leaving the map unchanged.
— intro'd in lesson 0007
- hash tag
- A
{...} substring in a key; only the braced part is hashed, forcing tagged keys
into the same hash slot. The way to make multi-key ops work in Cluster (else a
CROSSSLOT error, since multi-key ops require one slot).
— intro'd in lesson 0007
← lesson 0001 · All lessons