Comprehensive Guide to Redis: Usage, Performance, Data Types, Expiration Strategies, and Common Pitfalls

1. Why Use Redis

Redis is adopted primarily for its high performance and ability to handle massive concurrency, often serving as a cache for expensive, infrequently changing database queries such as those in flash‑sale systems.

Performance

By caching long‑running SQL results, subsequent requests can read directly from memory, dramatically reducing response time.

Concurrency

During heavy traffic, direct database access can cause connection failures; Redis acts as a buffer, absorbing requests before they reach the database.

2. Why a Single‑Threaded Redis Is Fast

Redis’s speed stems from three factors: pure in‑memory operations, a single‑threaded model that eliminates context switches, and a non‑blocking I/O multiplexing mechanism.

The I/O multiplexing model is illustrated with an analogy of a delivery service where a single driver (thread) manages many orders (I/O streams) efficiently.

3. Redis Data Types and Use Cases

String : Simple set/get, often used for counters.

Hash : Stores structured objects; useful for session‑like data (e.g., user info keyed by cookie ID).

List : Enables simple message queues and pagination via LRANGE.

Set : Stores unique values, supporting deduplication and set operations (union, intersection, difference).

Sorted Set : Adds a score for ordering, ideal for leaderboards and delayed tasks.

4. Expiration Policies and Memory Eviction

Redis combines periodic (random sampling every 100 ms) and lazy deletion to reclaim expired keys without excessive CPU load.

When memory is exhausted, various eviction policies can be configured in redis.conf: # maxmemory-policy volatile-lru noeviction : Writes fail when memory is full.

allkeys-lru : Evicts least‑recently‑used keys across the entire keyspace (commonly used).

allkeys-random : Randomly evicts keys.

volatile-lru : Evicts LRU keys only among those with an expiration.

volatile-random : Random eviction among expiring keys.

volatile-ttl : Evicts keys with the nearest expiration time.

5. Cache‑Database Dual‑Write Consistency

Dual writes can only guarantee eventual consistency; strong consistency requires bypassing the cache or employing a write‑then‑delete pattern with compensation mechanisms such as message queues.

6. Handling Cache Penetration and Snowballing

Cache penetration occurs when requests target non‑existent keys, forcing all traffic to the database; mitigation techniques include mutex locks, asynchronous refresh, and Bloom filters.

Cache snowballing happens when many keys expire simultaneously; solutions involve adding random jitter to TTLs, using double‑cache layers, and pre‑warming caches.

7. Solving Concurrent Key Competition

When multiple services set the same key, a distributed lock can serialize updates if order is unimportant; for ordered updates, timestamps or queues can enforce the correct sequence.

8. Summary

Redis is widely deployed in major Chinese tech companies (e.g., Sina, Alibaba, Tencent, Baidu, Meituan, Xiaomi). Mastery of Redis client usage, advanced features, persistence, replication, and high‑availability designs is essential for modern backend development.