Why Use Redis? Performance, Concurrency, and Common Pitfalls Explained

1. Why Use Redis

Analysis: The author considers using Redis mainly from two perspectives: performance and concurrency. Redis also provides features like distributed locks, but other middleware can replace those.

Performance

When a time‑consuming SQL query whose result changes infrequently is needed, caching the result in Redis allows subsequent requests to read from cache, achieving rapid response.

According to a traditional response‑time standard, an instant is about 0.36 seconds, a blink is 0.018 seconds, and a finger‑snap lasts 7.2 seconds.

Concurrency

Under high concurrency, direct database access can cause connection errors; using Redis as a buffer lets requests hit Redis first, reducing load on the database.

2. Drawbacks of Using Redis

Common issues include cache‑database double‑write consistency, cache avalanche, cache penetration, and cache concurrency competition.

Cache‑Database Consistency

To achieve eventual consistency, update the database first, then delete the cache; if cache deletion fails, use a compensating action such as a message queue.

Cache Avalanche

When many keys expire simultaneously, requests flood the database. Solutions: add random jitter to TTLs, use mutex locks, or employ a dual‑cache strategy.

Cache Penetration

Attackers request non‑existent keys, forcing all requests to the database. Mitigations: mutex locks, asynchronous updates with cache warm‑up, and Bloom filters to quickly reject invalid keys.

Cache Concurrency Competition

Multiple subsystems may try to set the same key. If order is not required, use a distributed lock. If order matters, store timestamps and apply the latest value, or serialize writes via a queue.

3. Why Is Single‑Threaded Redis So Fast

Redis operates in a single‑threaded model, avoiding context switches, using pure memory operations, and employing non‑blocking I/O multiplexing (select, epoll, evport, kqueue).

An analogy compares a thread‑per‑connection model to many delivery workers competing for a single vehicle versus a single worker managing multiple deliveries via I/O multiplexing.

4. Redis Data Types and Their Use Cases

Redis provides five core data types:

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

Hash : stores structured objects; useful for session‑like data.

List : can implement simple message queues or pagination.

Set : stores unique values, enabling global deduplication and set operations.

Sorted Set : includes a score for ordering, suitable for leaderboards, delayed tasks, and range queries.

5. Expiration Strategies and Memory Eviction

Redis uses periodic (every 100 ms) and lazy deletion for expired keys, combined with several eviction policies such as noeviction, allkeys‑lru, allkeys‑random, volatile‑lru, volatile‑random, and volatile‑ttl.

# maxmemory-policy volatile-lru

6. Cache‑Database Double‑Write Consistency

To maintain eventual consistency, update the database first, then delete the cache; if cache deletion fails, employ a compensating mechanism like a message queue.

7. Handling Cache Penetration and Avalanche

Solutions include mutex locks, asynchronous updates with cache warm‑up, Bloom filters for request validation, randomizing TTLs, and a dual‑cache strategy (cache A with TTL, cache B without TTL).

8. Solving Redis Key Concurrency Competition

For unordered operations, use a distributed lock. For ordered updates, store timestamps and apply the latest value, or serialize writes via a queue.

Selected Redis Articles

1. Using Redis to store Nginx+Tomcat load‑balancing session data

2. Redis introduction and differences from other caches

3. Detailed explanation of Redis's five data types

4. Persisting Redis data to disk with snapshots and AOF

5. Design pattern for Redis key naming

6. Solving distributed session sharing with Spring Session and Redis

7. Deep dive into Redis memory model

8. High‑availability Redis architecture analysis

9. Why Redis must be part of a distributed system

10. 50 essential Redis interview questions

11. Understanding Redis memory eviction policies

12. Optimizing hot keys for massive concurrent access