Mastering Redis: Persistence, Cache Pitfalls, Data Types, Clustering & Locks
This article explains Redis persistence mechanisms (RDB and AOF), common cache problems and their solutions, the various Redis data structures and their use cases, cluster deployment options, master‑slave replication, transaction commands, and how to implement distributed locks with SETNX and expiration.
Redis Overview
Redis is an in‑memory database that supports persistence by synchronizing data from memory to disk, allowing data recovery after a restart.
Persistence Mechanisms
<code>Redis uses a forked child process to copy the parent’s memory and write it to a temporary file, which then replaces the previous snapshot.</code>RDB : The default snapshot method saves the dataset to a binary file (dump.rdb) based on configurable
saveintervals. Advantages include faster startup for large datasets; disadvantages are potential data loss on crash and latency caused by the fork operation.
AOF : Every write command is appended to a log file, similar to MySQL binlog. On restart, Redis replays the log to rebuild the dataset. Advantages are higher data safety and configurable sync strategies; disadvantages are larger file size and slower performance compared to RDB.
Cache Issues and Solutions
Cache Avalanche
When many cached items expire simultaneously, a surge of database requests can overload the system. Mitigation includes staggering expiration times or using locks/queues to limit concurrent database access.
Cache Penetration
Requests for non‑existent keys bypass the cache and hit the database repeatedly. Common solutions are Bloom filters to block impossible keys or caching empty results with a short TTL.
Bloom Filter (Recommended)
Uses multiple independent hash functions to test set membership with controlled false‑positive rates, providing efficient space usage for large datasets.
Cache Breakdown (Hot Key)
When a hot key expires, a burst of requests can hit the database. Using
SETNXto create a short‑lived lock key can serialize access while the cache is being rebuilt.
Redis Data Types and Use Cases
String : Simple
SET/GET, suitable for counters and basic caching.
Hash : Stores structured objects; useful for session‑like data (e.g., user info keyed by token).
List : Supports FIFO queues, message queues, and pagination via
LRANGE.
Set : Holds unique values, enabling global deduplication, set operations (union, intersection, difference).
Sorted Set : Adds a score for ordering, ideal for leaderboards and top‑N queries.
Redis Cluster Solutions
twemproxy : A proxy that uses consistent hashing to route requests; does not automatically rebalance data when nodes change.
Codis : Similar to twemproxy but supports data migration when the node count changes.
Redis Cluster (3.0+) : Uses hash slots instead of pure consistent hashing and supports native master‑slave replication.
Multi‑Machine Deployment and 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
MULTIand executed atomically on
EXEC. Redis does not roll back on failure; if a command errors, the remaining commands are still processed.
Distributed Lock with Redis
Use
SETNXto create a lock key only if it does not exist, and release it with
DEL. To avoid deadlocks, set an expiration with
EXPIREor combine
SETNXand
GETSETto enforce a maximum lock time.
Raymond Ops
Linux ops automation, cloud-native, Kubernetes, SRE, DevOps, Python, Golang and related tech discussions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.