Mastering Redis: Expiration Strategies, Memory Management, and Transactions

Expiration Strategies

Redis provides three key expiration strategies: active (timed) expiration, lazy expiration, and periodic expiration. Active expiration creates a timer for each key with a TTL and removes it immediately when the timer fires, which is memory‑friendly but CPU‑intensive. Lazy expiration checks a key’s TTL only when the key is accessed, saving CPU at the cost of potentially retaining many expired keys in memory. Periodic expiration scans a configurable number of keys in the expires dictionary at regular intervals, offering a balance between CPU and memory usage.

Redis combines lazy and periodic expiration by default.

Setting Expiration and Persistence

The EXPIRE command sets a TTL for a key, while PERSIST removes the TTL, making the key permanent.

Handling Expired Data

Beyond Redis’s built‑in expiration, users can implement custom eviction: either schedule a background job to delete expired entries or check expiration on each request and refresh the cache from the underlying data source.

Memory‑Related Topics

When the dataset grows, Redis applies an eviction policy if memory limits are reached. The main policies are:

noeviction : writes fail when memory is exhausted.

allkeys‑lru : evicts the least recently used key among all keys (most common).

allkeys‑random : evicts a random key.

volatile‑lru : evicts the least recently used key among keys with an expiration.

volatile‑random : evicts a random key among keys with an expiration.

volatile‑ttl : evicts keys with the nearest expiration time first.

Redis primarily consumes memory; when the memory limit is reached, write commands return errors (reads still work) or the configured eviction policy discards older data.

Memory optimisation tips include using compact data structures such as hashes, lists, sets, and sorted sets, and storing related fields of an object in a single hash instead of separate keys.

Thread Model

Redis follows a single‑threaded Reactor pattern. A file‑event handler monitors multiple sockets using I/O multiplexing, dispatches events to the appropriate handlers, and processes commands sequentially. Although the event loop runs in one thread, the multiplexing allows high‑throughput network communication while keeping the internal design simple.

Transactions

A Redis transaction groups commands between MULTI and EXEC. All commands are queued and then executed atomically in order, without interleaving from other clients. Redis does not support rollback; if a command fails, the remaining commands still run.

Key transaction commands: MULTI: start a transaction. EXEC: execute all queued commands. DISCARD: abort the transaction and clear the queue. WATCH: optimistic lock that monitors one or more keys; if any watched key changes before EXEC, the transaction aborts.

Redis transactions provide atomicity for individual commands but not full ACID guarantees. Consistency and isolation are ensured, while durability depends on the persistence configuration (e.g., AOF with appendfsync always).

Alternative approaches include Lua scripts, which execute a sequence of commands atomically, and custom flag‑based mechanisms to track transaction completion.

Source: https://blog.csdn.net/ThinkWon/java/article/details/103522351