Mastering Redis: Persistence, Caching Strategies, Data Types, and Clustering

Redis Persistence Mechanisms

Redis is an in‑memory database that supports persistence by synchronizing data to disk. When Redis restarts, it reloads the snapshot file to restore data.

Implementation: a child process is created via fork() to copy the parent’s memory, write to a temporary file, replace the previous snapshot, and then exit.

RDB is the default snapshot‑based persistence. The snapshot is saved to dump.rdb according to the save configuration (e.g., save 120 1 means persist if at least one key changes within two minutes). Advantages: faster startup for large datasets. Disadvantages: possible data loss on crash and latency caused by the fork operation.

RDB configuration examples: save 120 1, dbfilename dump.rdb, dir ./.

AOF appends every write command to appendonly.aof. On restart, Redis replays the commands to rebuild the dataset. Advantages: higher durability, three sync strategies (always, everysec, no), automatic rewrite to keep file size manageable. Disadvantages: larger file size and slower performance compared with RDB.

AOF configuration: set appendonly yes, choose sync policy via appendfsync (always, everysec, no).

If both RDB and AOF are enabled, Redis prefers AOF for recovery.

Caching Issues and Solutions

Cache Avalanche

Occurs when many cached items expire simultaneously, causing a sudden surge of database queries that can overload the DB. Mitigation: use distributed locks or queues, or stagger expiration times.

Cache Penetration

When requests query non‑existent data, they bypass the cache and hit the database each time. Mitigation: employ a Bloom filter to block impossible keys, or cache empty results with a short TTL.

Bloom Filter (Recommended)

Uses multiple independent hash functions (k > 1) to test membership with low false‑positive rate and high space efficiency. Suitable for large‑scale existence checks.

Difference between cache penetration and cache breakdown (stampede): cache breakdown happens for hot keys that expire, leading to massive concurrent DB hits. Solution: use SETNX to lock the key during refresh.

Redis Data Types and Typical Use Cases

String : basic SET/GET, suitable for simple values or counters.

Hash : stores structured objects; useful for session data such as user info keyed by a token.

List : implements simple queues, message streams, or pagination via LRANGE.

Set : holds unique elements; ideal for global deduplication, set operations (intersection, union, difference).

Sorted Set : adds a score for ordering; perfect for leaderboards and top‑N queries.

Redis Cluster Solutions

Twemproxy : a proxy that uses consistent hashing to route requests. Drawback: single‑port bottleneck and no automatic data migration when nodes change.

Codis : similar to Twemproxy but supports data migration when the cluster topology changes.

Redis Cluster 3.0 : built‑in clustering using hash slots and native replica support.

Multi‑Machine Deployment and Data Consistency

Master‑slave replication provides read‑write separation. The master handles writes and propagates changes to one or more read‑only slaves.

Redis Transactions

Implemented with MULTI, EXEC, DISCARD, and WATCH. Commands are queued after MULTI and executed atomically on EXEC. Redis does not roll back on failure; if a command errors, the remaining commands are still processed. WATCH adds optimistic locking by monitoring keys for changes before execution.

Distributed Lock with Redis

Use SETNX to acquire a lock; release with DEL. Prevent deadlocks by setting an expiration with EXPIRE or combining SETNX and GETSET to store a timestamp.