Nine Essential Aspects of Redis: A Comprehensive Technical Guide

1. Redis Basics

Redis is a key‑value, in‑memory NoSQL database. Although its network I/O and basic read/write operations run on a single thread, auxiliary tasks such as persistence, asynchronous deletion, and cluster synchronization use additional threads.

The speed comes from memory‑level operations and the avoidance of thread‑switch overhead.

2. Core Data Structures and Typical Use Cases

Redis supports five primary data structures: String , Hash , List , Set , and ZSet . The article illustrates concrete commands for each:

String – simple cache : set key value, get key Hash – object cache (e.g., distributed session) : hmset user name boom age 25, hmget user name age Counter – rate limiting, view count : incr num, decr num, incrby num N, decrby num N Distributed lock : setnx key value (returns 1 on success)

Hash example – shopping cart : hset cart_userId productId quantity, hincrby cart_userId productId delta, hlen cart_userId, hdel cart_userId productId, hgetall cart_userId List – queue and stack : lpush listKey value + rpop listKey (FIFO), lpush listKey value + lpop listKey (FILO), lpush listKey value + brpop listKey (blocking queue). Example: push messages for a public account and retrieve the latest four with lrange msg_accountId 0 4.

Set – set operations : sinter set1 set2 set3, sunion set1 set2 set3, sdiff set1 set2 set3. Classic use case: modeling a social‑media follow graph.

ZSet – sorted set for ranking : commands such as zadd key score member, zrem key member, zscore key member, zrange key start stop [WITHSCORES], zrevrange key start stop [WITHSCORES]. Example: building a hot‑news leaderboard.

3. Persistence Mechanisms

Redis offers three persistence modes: RDB , AOF , and Hybrid .

RDB creates a binary snapshot (dump.rdb). The save directive triggers a snapshot when the dataset changes at least M keys within N seconds (e.g., save 60 1000). save is synchronous; bgsave forks a child process to write the snapshot asynchronously.

AOF appends every write command to appendonly.aof. The appendfsync policy can be always (safe but slow), everysec (default, balances speed and safety), or no (fast but unsafe).

Hybrid persistence combines an RDB snapshot with incremental AOF updates, reducing restart time for large datasets. It is enabled with aof-use-rdb-preamble yes.

4. Replication, Sentinel, and Cluster

Master‑Slave Replication uses the SYNC command (pre‑2.8) or PSYNC (2.8+). The master creates an RDB snapshot via bgsave, streams it to the slave, and then sends buffered write commands. Partial synchronization reuses a cached offset when the connection drops.

Sentinel monitors master health, performs failover, and elects a leader among Sentinels. A typical deployment uses three Sentinels to avoid split‑brain scenarios.

Cluster shards data across up to 16384 slots. Clients hash a key with CRC16, mod 16384, to locate the slot. Nodes exchange metadata via a gossip protocol; the cluster can operate with cluster-require-full-coverage no to stay available despite missing slots.

5. Eviction Policies

Because Redis stores data in memory, it employs two eviction strategies:

Timed deletion : periodically samples 20 keys from the expiration dictionary and removes expired ones. If more than a quarter are expired, the process repeats.

Lazy deletion : removes a key when a client accesses it and finds it expired.

If memory reaches maxmemory, Redis applies an eviction policy (default noeviction) to free space.

6. Progressive Rehash

Redis dictionaries use two hash tables ( ht[0] and ht[1]). When resizing, a new table twice the size is allocated, and entries are moved incrementally during normal CRUD operations. The rehash index rehashidx tracks progress; when it reaches –1, rehashing is complete.

During rehash, reads check both tables, and new writes go directly to ht[1], ensuring ht[0] only shrinks.

7. Skiplist (ZSet) Implementation

ZSet combines a hash table (value‑to‑score mapping) with a skiplist for ordered score traversal. The skiplist has up to 64 levels; each node’s level is chosen randomly (probability halves each level).

struct zslnode { string value; double score; zslnode* forwards[]; zslnode* backward; }</code>
<code>struct zsl { zslnode* header; int maxLevel; map<string, zslnode*> ht; }

Search starts at the top level of the header and drops down until the target is found, achieving O(log n) complexity.

Insertion determines a random level K and inserts the node into each level up to K. Deletion removes the node from all levels where it appears.

8. Bitmap for Massive Active‑User Counting

A bitmap is a byte array where each bit represents a user ID. For 100 million users, the bitmap consumes ~11 MiB. Setting a bit on login: setbit key userId 1. Counting active users: bitcount key.

Weekly active users are obtained with bitop or result day1 day2 … day7 followed by bitcount result. Continuous weekly login detection uses bitop and and getbit result userId.

9. MySQL‑Redis Dual‑Write Consistency

In high‑concurrency scenarios, writes to MySQL and Redis can become inconsistent. Solutions include:

Accept occasional staleness for low‑conflict data and rely on TTL‑based cache refresh.

Use read‑write locks to serialize writes when strict consistency is required.

Employ Alibaba’s Canal to capture MySQL binlog events and update Redis in real time, at the cost of added middleware complexity.

For read‑heavy, write‑light workloads, caching remains beneficial; for write‑heavy workloads that cannot tolerate inconsistency, bypassing the cache may be preferable.

Conclusion

The article systematically covers Redis’s architecture, data structures, persistence, high‑availability mechanisms, memory management, internal algorithms, and practical integration patterns, providing a solid foundation for engineers to design, tune, and troubleshoot Redis‑based systems.