Understanding Redis: NoSQL Basics, Data Types, Persistence, Replication, Sentinel and Cache Issues

Redis is an open‑source, in‑memory key‑value store that belongs to the NoSQL family, offering various data structures such as strings, lists, sets, sorted sets, hashes, bitmaps, HyperLogLog and geospatial indexes.

The article first explains the difference between relational databases and NoSQL, then introduces Redis fundamentals, including its five basic data types and the underlying storage mechanisms (embstr, raw, ziplist, quicklist, dict, skiplist, intset, etc.) with representative C structures.

Underlying structures:

typedef struct dictEntry {
    void *key;
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;
    struct dictEntry *next;
} dictEntry;

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:22;
    int refcount;
    void *ptr;
} robj;

typedef struct quicklist {
    struct quicklistNode *head, *tail;
    unsigned long count;
    int len;
    int fill : 16;
    unsigned int compress : 16;
} quicklist;

typedef struct zskiplist {
    struct zskiplistNode *header, *tail;
    unsigned long length;
    int level;
} zskiplist;

Special data types such as geospatial indexes, HyperLogLog and Bitmaps are described together with typical use‑cases like nearby‑user queries, UV counting and binary flag storage.

Redis transactions are covered, highlighting the MULTI/EXEC workflow, error handling, and the lack of rollback support, which keeps the engine simple and fast.

Two persistence models – RDB snapshots and Append‑Only Files (AOF) – are compared, detailing their generation, configuration options, advantages and drawbacks, and the AOF rewrite process that compacts the log while preserving data integrity.

The publish/subscribe mechanism, both channel‑based and pattern‑based, is explained with its internal dictionary and list structures that map channels or patterns to subscriber client lists.

Master‑slave replication is described, including full‑sync and incremental sync phases, and the role of RDB snapshots during replication to transfer the dataset while buffering concurrent writes.

Sentinel provides automatic failover, using subjective/objective down detection, leader election (a Raft‑like quorum algorithm), and slave promotion criteria based on offset, priority and run‑id, ensuring high availability.

Finally, common cache problems – cache penetration, cache breakdown, and cache avalanche – are identified and mitigated through input validation, short‑TTL null caching, Bloom filters, mutex locks, staggered expiration and hot‑key protection.