Comprehensive Guide to Redis: Architecture, Data Structures, Persistence, Replication, Clustering, and Advanced Features
This article provides an in‑depth overview of Redis, covering its single‑threaded architecture, core data structures (String, Hash, List, Set, ZSet), persistence mechanisms (RDB, AOF, hybrid), replication, Sentinel and cluster designs, memory eviction policies, bitmap analytics, skiplist implementation, and strategies for ensuring data consistency.
Redis is an in‑memory key‑value store known for its high performance, and this article explains its architecture, data structures, persistence options, replication mechanisms, clustering, memory management, bitmap analytics, and internal implementations.
Single‑threaded model : Although Redis processes network I/O and command execution in a single thread, auxiliary tasks such as persistence, asynchronous deletion, and cluster synchronization run in additional threads.
Core data structures : Redis provides five primary types—String, Hash, List, Set, and ZSet. Examples include simple key‑value caching ( SET key value , GET key ), object caching with MSET / MGET , counters using INCR , DECR , INCRBY , DECRBY , distributed locks with SETNX , hash‑based object storage ( HMSET / HMGET ) for shopping carts, list‑based queues and stacks ( LPUSH / RPOP , LPOP ), set operations for social graphs ( SINTER , SUNION , SDIFF ), and sorted‑set commands for ranking ( ZADD , ZINCRBY , ZUNIONSTORE , ZINTERSTORE , ZRANGE , ZREVRANGE ).
Persistence : Redis supports RDB snapshots ( SAVE , BGSAVE ), AOF append‑only logs ( appendonly yes , appendfsync always/everysec/no ), and a hybrid mode that combines an RDB preamble with AOF increments ( aof-use-rdb-preamble yes ). The article lists the configuration commands and compares their durability and performance.
Replication and high availability : Master‑slave replication uses SYNC / PSYNC , with partial synchronization via offset tracking. Sentinel monitors instances, performs leader election, and handles failover. Redis Cluster distributes data across 16384 slots, uses a gossip protocol for metadata exchange, and supports automatic slot rebalancing.
Memory eviction : When maxmemory is reached, Redis applies policies such as volatile‑LRU, allkeys‑LFU, and others; it also performs periodic and lazy expiration of keys.
Bitmap statistics : Bitmaps store billions of bits efficiently; commands SETBIT , BITCOUNT , and BITOP enable fast daily, weekly, and monthly active‑user calculations.
Internal skiplist implementation : ZSet is built from a hash table and a skiplist. The article shows the C‑like struct definitions: struct zslnode { string value; double score; zslnode* forwards[]; // multi‑level pointers zslnode* backward; // back‑pointer }; struct zsl { zslnode* header; // skiplist head int maxLevel; // current highest level map ht; // hash table for fast lookup }; It describes insertion, search (O(log n)), and deletion processes.
Data consistency between MySQL and Redis : In high‑concurrency scenarios, write‑through and read‑through can cause stale data. Solutions include short TTLs, read‑write locks, or using binlog‑based tools like Canal to synchronize changes.
Architect's Guide
Dedicated to sharing programmer-architect skills—Java backend, system, microservice, and distributed architectures—to help you become a senior architect.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.