Comprehensive Guide to Common Redis Issues and Their Solutions

1. Why Use Redis

Redis is adopted mainly for performance and concurrency; it can also serve as a distributed lock, though other middleware (e.g., Zookeeper) can replace that function.

2. Drawbacks of Using Redis

The most common problems are cache‑database double‑write consistency, cache avalanche, cache penetration, and cache concurrency competition.

3. Why a Single‑Threaded Redis Is So Fast

Redis achieves high speed through pure in‑memory operations, a single‑threaded model that avoids context switches, and non‑blocking I/O multiplexing (select, epoll, evport, kqueue).

4. Redis Data Types and Their Scenarios

String – basic Set/Get, often for simple counters. Hash – stores structured objects; useful for session‑like data (e.g., user info keyed by cookie ID). List – can implement simple message queues or pagination via Lrange. Set – stores unique values, ideal for global deduplication and set operations (intersection, union, difference). Sorted Set – adds a score for ordering, enabling leaderboards, delayed tasks, and range queries.

5. Expiration Policies and Memory Eviction

Redis uses a combination of periodic deletion (every 100 ms a random subset of keys is checked) and lazy deletion (keys are removed when accessed after expiration). When memory is exhausted, various eviction policies can be configured, such as # maxmemory-policy volatile-lru, Noeviction , Allkeys‑lru , Allkeys‑random , Volatile‑lru , Volatile‑random , and Volatile‑ttl .

6. Cache‑Database Double‑Write Consistency

Strong consistency requires avoiding cache altogether; otherwise, only eventual consistency can be achieved. Common practice is to update the database first, then delete the cache, and use compensating mechanisms (e.g., message queues) to handle cache‑deletion failures.

7. Dealing with Cache Penetration and Cache Avalanche

Cache penetration is mitigated with mutex locks, asynchronous updates, or Bloom filters to quickly reject illegal keys. Cache avalanche is addressed by adding random jitter to TTLs, using mutex locks, or employing a dual‑cache strategy (Cache A with TTL, Cache B without TTL and pre‑warming).

8. Solving Redis Concurrent Key Competition

If order is not required, a distributed lock can serialize Set operations. If order matters, timestamps are stored with each value; when a lock is acquired, the timestamp is compared to the existing one to decide whether to overwrite. Queues can also serialize access.

9. Summary

The article consolidates common Redis questions encountered in interviews and real projects, covering usage rationale, performance characteristics, data structures, expiration and eviction mechanisms, consistency issues, and practical mitigation techniques for cache‑related problems.