Databases 13 min read

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.

Raymond Ops
Raymond Ops
Raymond Ops
Mastering Redis: Persistence, Cache Pitfalls, Data Types, Clustering & Locks

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

save

intervals. 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

SETNX

to 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

MULTI

and 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

SETNX

to create a lock key only if it does not exist, and release it with

DEL

. To avoid deadlocks, set an expiration with

EXPIRE

or combine

SETNX

and

GETSET

to enforce a maximum lock time.

CacheClusteringRedisPersistenceDistributed LockData TypesTransactions
Raymond Ops
Written by

Raymond Ops

Linux ops automation, cloud-native, Kubernetes, SRE, DevOps, Python, Golang and related tech discussions.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.