"Redis" now names more than one thing, and the licence matters if you ship or host it. Everything below was read from redis.io (the 2024-03-20 licensing blog post, the 2025-05-01 AGPLv3 post and the legal/licenses page) and valkey.io on 2026-10-31.

What this means in practice: the wire protocol and the commands in this page work the same on Redis and on Valkey (the examples were run against redis:7 = 7.4.12, redis:8 = 8.10.3 and valkey/valkey:8/valkey/valkey:9). Managed services (ElastiCache, Memorystore, Azure) have their own offerings and their own version lists. New commands diverge: DELEX and SET ... IFEQ exist in Redis 8.4 and later (chapter 8), and each project adds features the other does not. Pin your client library, test on the engine you really deploy, and ask your legal team which licence terms apply if you redistribute or offer Redis as a service.

Keys are binary-safe strings, but treat them like an API. A good key is readable, namespaced, bounded and versioned.

EXPIRE key seconds (or SET key v EX seconds, PEXPIRE for milliseconds, EXPIREAT for a timestamp) attaches a time to live. TTL returns the remaining seconds, -1 if the key has no expiry and -2 if the key does not exist. PERSIST removes the TTL. **Overwriting a key with SET clears its TTL** unless you pass KEEPTTL.

Expiry is lazy plus active. Lazy: when a command touches an expired key Redis deletes it and behaves as if it never existed. Active: Redis periodically tests a few keys at random among those with a TTL and deletes the expired ones, so memory is reclaimed even for keys nobody reads. A consequence worth knowing: INFO keyspace shows keys=17,expires=2,avg_ttl=..., and a key whose time has passed can still occupy memory for a short while until a cycle or an access removes it. Replicas do not expire keys themselves: they wait for the DEL from the primary.

With maxmemory 0 (the default) Redis uses all memory the OS will give it. In production set maxmemory below the machine or container limit (leave room for replication buffers, fork copy-on-write and fragmentation) and pick a policy. All eight names below were accepted by CONFIG SET maxmemory-policy on the Redis 7.4.12 image (an invalid name returns the list), and the default is noeviction.

The volatile-* policies behave like noeviction when no key has a TTL, a classic way to get OOM errors in a "cache" where someone forgot to set expiries. **Newer Redis 8.x lines add two more names, allkeys-lrm and volatile-lrm (least recently modified)**: they were accepted by Redis 8.10.3 and rejected by 7.4.12 in the test for this page, and appear on the current eviction docs page. Do not rely on them if you run 7.x or Valkey.

LRU and LFU are approximated: Redis samples maxmemory-samples keys (default 5) and evicts the best candidate among them, which is cheap and close to exact LRU. Raising the sample size is more precise and costs CPU.

A replica connects to a primary, receives a snapshot, and then a continuous stream of write commands. Replication is asynchronous by default: the primary acknowledges your write to you without waiting for any replica. That keeps latency low and means a primary crash can lose the last writes that never reached a replica.

• REPLICAOF host port makes a node a replica (in redis.conf as replicaof). Replicas are read-only by default; reading from them can return stale data (replication lag).
• WAIT numreplicas timeout blocks the calling connection until the replicas have acknowledged the preceding writes of that connection, or the timeout (milliseconds) passes. It returns how many replicas acknowledged. It narrows the loss window; it does not turn Redis into a strongly consistent store, because a failover can still elect a replica that missed something.
• A replica that reconnects after a short outage can often do a partial resynchronisation from the primary's replication backlog instead of a full copy.

Hash slots. The key space is divided into 16384 slots; a key's slot is CRC16(key) mod 16384. Each primary owns a range of slots. When a client sends a command to a node that does not own the key's slot, the node replies **MOVED slot host:port (a permanent redirect: update your slot map). While a slot is being migrated, the node can reply ASK**, a one-time redirect to the target, which the client must precede with ASKING. Good clients (Lettuce, Jedis, redis-py cluster mode) do all of this for you.

Hash tags. If a key contains {...} with at least one character inside, only that part is hashed. {user:1}:cart and {user:1}:profile land in the same slot, so MULTI/EXEC, Lua scripts and multi-key commands over them work. The trade-off: if you tag everything with the same value you have built one hot shard.

The default caching pattern: the application reads the cache, on a miss reads the database, then writes the cache with a TTL (SET product:42 <json> EX 600). All the difficult parts - stampedes, penetration, invalidation races, sizing - are the subject of page 06, Caching Patterns; the Spring annotation side is in Spring: Caching and Resilience.

A session store is the same idea with a TTL that slides: SET session:<id> <data> EX 1800, and EXPIRE session:<id> 1800 on each request (or GETEX session:<id> EX 1800 to read and extend in one command). Because Redis is shared, the app servers stay stateless. Decide what a lost session costs: a forced login is usually acceptable, which is why a snapshot-only Redis is a common choice.

The simplest limiter counts requests per user per window. The first INCR creates the key, so that is when you set the expiry. The weakness is the boundary: a client can send the limit at 11:59:59 and again at 12:00:00, doubling the rate for a moment.

Keep one sorted set per user, members are request ids and scores are timestamps. For each request: remove entries older than the window, count what is left, add this request if under the limit. This is exact, at the cost of memory proportional to the limit. The script below was run for real (limit 3, window 60 s, timestamps 1100 to 1400 ms, then 70000 ms).

The script takes now as an argument instead of calling TIME inside, which keeps the example deterministic; in production pass the client clock or call redis.call('TIME'). In Cluster the single key rl:user:42 is fine. A cheaper approximation is the sliding window counter (two fixed-window counters weighted by overlap), and a smoother alternative is a token bucket kept in a hash with a script. Pick by how exact the limit must be.

A lock in Redis is a key that exists only while someone holds it: SET lock:order:42 <random token> NX PX 30000. NX means set only if absent, PX gives it a lifetime so a crashed owner cannot hold it forever. The token identifies the owner, so that release is conditional: delete only if the value still equals my token. A plain DEL could delete somebody else's lock after yours expired.

On Redis 8.4 and later the compare-and-delete script is built in: DELEX key IFEQ value deletes the key only if its value equals the argument. It returned 0 for a wrong token and 1 for the right one on the 8.10.3 image, and SET key value IFEQ expected (conditional overwrite, same version) also worked. On 7.x and Valkey use the Lua script.

• Efficiency locks ("avoid doing the same job twice"): fine. If the lock occasionally fails, the cost is duplicate work.
• Correctness locks ("two writers must never both modify this"): a TTL lock cannot guarantee it alone. The owner can be paused (garbage collection, a slow network call, a suspended VM) past the TTL; the lock expires; a second client acquires it; the first wakes up and still believes it holds the lock, exactly as in the diagram. Clocks and failovers add further ways to break mutual exclusion: Redis replication is asynchronous, so a primary can crash after granting a lock and before the replica sees it, and the promoted replica grants the same lock again (the Redis docs make this very point).
• Fencing tokens fix the dangerous case: the lock service hands out an increasing number with each grant, the client sends it with every write, and the resource rejects writes with a token lower than one it has already seen. This needs support in the protected resource (a database column, a conditional update such as WHERE version = ?). Redis can generate tokens with INCR, but the check must happen where the data lives.

Redlock is the algorithm in the Redis documentation for locking across several independent Redis primaries (typically five): acquire on a majority within a time limit shorter than the lock validity, and treat the lock as held for the remaining validity. On 8 February 2016 Martin Kleppmann published an analysis ("How to do distributed locking") arguing that Redlock is unsafe for correctness locks because it depends on timing assumptions (bounded pauses, bounded clock drift) and has no fencing token; Salvatore Sanfilippo (antirez) answered the next day ("Is Redlock safe?"), defending the design and arguing the assumptions are reasonable. The Redis lock documentation itself links both articles, tells you that if you care about correctness you should implement fencing tokens, and presents Redlock as the algorithm to "model" its guarantees. The honest summary: Redlock is reasonable for efficiency locks; for correctness, rely on fencing or on a system built for consensus (for example a lock or lease in ZooKeeper, etcd or your database). Read both articles and decide for your risk.

A leaderboard is a sorted set: ZINCRBY lb:weekly 10 asha on each score event, ZREVRANGE lb:weekly 0 9 WITHSCORES for the top ten, ZREVRANK lb:weekly asha for one player's position (all O(log N) or O(log N + M)). The session in chapter 2 shows real output. Reset a period by writing to a new key (lb:2026-W44) and letting the old one expire.

An idempotency key makes a retried request safe: SET idem:<client key> <result or "in-progress"> NX EX 86400. If SET returns OK you are the first and you process the request; if it returns nil, the request is a duplicate and you return the stored result or a "being processed" answer. Store the final response under the key once finished. Redis alone is not enough if the business effect is in another database: make the effect itself idempotent as well (see Messaging fundamentals).

Tools to look: SLOWLOG GET 10 (commands slower than slowlog-log-slower-than, default 10000 microseconds), LATENCY DOCTOR, INFO commandstats, redis-cli --latency, and MONITOR (only briefly: it slows the server).

• Types. Build a user hash, a tags set and a leaderboard sorted set. Run TYPE and OBJECT ENCODING on each, then add 600 members to the set and check the encoding again.
• Expiry. SET k v PX 200, wait, GET k. Then SET k v EX 100, SET k v2, TTL k - what happened to the TTL? Retry with KEEPTTL.
• Eviction. Start a server with --maxmemory 3mb --maxmemory-policy allkeys-lru, load 4000 keys of 1 KB, read INFO stats for evicted_keys. Switch to noeviction with CONFIG SET and try one more write.
• Persistence. Start with --appendonly yes, write a key, docker restart, read it back. Look inside the appendonlydir volume. Repeat with persistence off and see the key vanish.
• Cluster slots. Start with --cluster-enabled yes, CLUSTER ADDSLOTSRANGE 0 16383 and run CLUSTER KEYSLOT on keys with and without hash tags.
• Lock. Reproduce the lock session of chapter 8, then let the TTL expire between two acquires.
• Stream. Start two consumers in a group, kill one without XACK, and recover its entry with XAUTOCLAIM.