Comprehensive Guide to Redis: Fundamentals, Persistence, High Availability, and Advanced Topics

1. What is Redis?

Redis is a key‑value NoSQL database that stores all data in memory, offering high read/write performance and supporting various data structures such as strings, hashes, lists, sets, sorted sets, bitmaps, HyperLogLog, and GEO.

2. Common Use Cases

Typical scenarios include caching, counters, leaderboards, social networking features, message queues, and distributed locks, often illustrated with e‑commerce user‑service examples.

3. Redis Data Structures

Redis provides five basic structures: string (binary‑safe up to 512 MB), hash (field‑value maps), list (ordered strings, usable as stack or queue), set (unordered unique strings), and sorted set (elements ordered by a score).

4. Why is Redis Fast?

Performance stems from in‑memory operations, single‑threaded execution (avoiding context switches), non‑blocking I/O multiplexing, and a highly optimized C implementation.

5. I/O Multiplexing

Redis uses select/poll/epoll to handle many connections efficiently, processing I/O only during these system calls while the rest of the thread remains idle.

6. Thread Model

Historically single‑threaded, Redis 6.0 introduced optional multithreading for network I/O and protocol parsing, while command execution stays single‑threaded.

7. Persistence

Two mechanisms exist: RDB snapshots (saved with save or bgsave ) and AOF append‑only logs (configured with appendfsync options like always ), each with distinct trade‑offs.

8. RDB vs AOF

RDB offers compact binary files and fast recovery but lower real‑time durability; AOF provides real‑time persistence at the cost of larger files and slower recovery.

9. Choosing Persistence

Best practice is to enable both, letting AOF handle fast recovery while RDB serves as a backup snapshot.

10. High Availability

Redis achieves HA through master‑slave replication, Sentinel for automatic failover, and Redis Cluster for sharding and fault tolerance.

11. Sentinel

Sentinel monitors instances, performs subjective and objective failovers, elects a leader (using Raft‑like consensus), and notifies clients of the new master.

12. Redis Cluster

Cluster partitions data across 16384 slots, distributes slots among nodes, and provides automatic failover; it uses hash slots and supports scaling by adding or removing nodes.

13. Cache Design Patterns

Key concepts include cache breakdown, cache penetration, and cache avalanche, with mitigation strategies such as locking, cache‑aside pattern, Bloom filters, staggered expirations, multi‑level caches, and circuit‑breaker mechanisms.

14. Consistency Between Cache and Database

Approaches include delete‑then‑update, delayed double‑delete, message‑queue‑driven invalidation, and setting reasonable TTLs to achieve eventual consistency.

15. Hot Keys and Scaling

Detect hot keys via client, proxy, or server monitoring, then mitigate by sharding, adding secondary caches, or using multi‑level caching.

16. Operational Issues

Common problems include memory exhaustion (adjust maxmemory and eviction policies), large‑key handling (use UNLINK or split data), blocking operations, and the “no‑bottom‑hole” effect when scaling clusters.

17. Advanced Features

Redis supports transactions (MULTI/EXEC), Lua scripting for atomic operations, pipelining to reduce RTT, and distributed locks via SETNX with expiration (or Redisson libraries).

18. Internal Data Structures

Core structures include SDS (dynamic strings), linked lists, hash tables (dict) with incremental rehashing, skip lists for sorted sets, intsets for integer sets, and ziplists/compressed lists for memory‑efficient storage. Quicklist combines ziplist and linked list for list implementation.