Redis Deep Dive: Why Use It, Pitfalls, and Practical Solutions

Redis is widely used for caching and fast data access, but many developers only know the basic SET and GET commands. This guide summarizes common Redis questions to fill knowledge gaps.

1. Why Use Redis

Redis improves performance and handles high concurrency by storing frequently accessed, rarely changing data in memory, reducing expensive database queries. It also offers features like distributed locks, though dedicated lock services (e.g., ZooKeeper) may be preferable for pure locking needs.

2. Drawbacks of Redis

Cache‑database write inconsistency

Cache avalanche

Cache penetration

Concurrent key competition

Solutions for each problem are discussed later.

3. Why a Single‑Threaded Model Is Fast

Pure in‑memory operations

Single thread avoids context switches

Non‑blocking I/O multiplexing (select/epoll/kqueue)

An analogy compares multiple threads handling each I/O stream (traditional model) with a single thread managing many streams via I/O multiplexing, which is more efficient.

4. Redis Data Types and Use Cases

String : Simple key‑value, often for counters.

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

List : Simple message queue or pagination via LRANGE.

Set : Global deduplication across a cluster.

Sorted Set : Leaderboards, delayed tasks, range queries (ordered by score).

5. Expiration Policies and Memory Eviction

Redis uses a combination of periodic deletion (random sampling every 100 ms) and lazy deletion (on access). When memory is exhausted, several eviction policies can be configured in redis.conf:

Noeviction : Writes fail when memory is full.

Allkeys‑lru : Remove least‑recently‑used keys globally (commonly used).

Allkeys‑random : Randomly evict keys.

Volatile‑lru , Volatile‑random , Volatile‑ttl : Apply only to keys with an expiration set.

If no keys have an expiration, volatile policies behave like Noeviction.

6. Cache‑Database Write Consistency

Strong consistency requires avoiding cache altogether; otherwise, only eventual consistency can be achieved. Typical mitigation includes updating the database first, then deleting the cache, and using compensating actions (e.g., message queues) if cache deletion fails.

7. Dealing with Cache Penetration and Avalanche

Penetration : Use mutex locks, asynchronous refresh, or a Bloom filter to reject illegal keys.

Avalanche : Add random jitter to TTLs, employ mutexes (with throughput trade‑off), or implement a dual‑cache strategy (one short‑TTL cache A, one long‑TTL cache B with pre‑warming).

8. Solving Concurrent Key Competition

When multiple services set the same key, a distributed lock works if order is irrelevant. If order matters, store timestamps with values and let later timestamps overwrite earlier ones, or serialize writes via a queue.

9. Conclusion

The article consolidates practical Redis knowledge—performance advantages, single‑threaded architecture, data structures, expiration and eviction mechanisms, consistency considerations, and concrete mitigation techniques for common pitfalls—aimed at helping developers apply Redis effectively in real projects.