Redis Overview: Features, Data Types, Caching Issues, Persistence, Replication, and Sentinel

Redis Introduction – Redis is an open‑source, high‑performance, in‑memory key‑value store written in C, usable as a database, cache, or message broker and classified as a NoSQL database.

Key Characteristics

Single‑threaded but process‑safe, using I/O multiplexing.

Can serve as a distributed lock.

Supports five primary data types.

Provides data persistence to disk.

Can be used as a message middleware with publish/subscribe.

Data Types

The following image illustrates the five data types and typical use cases:

Cache Usage in Spring Boot

Direct use via RedisTemplate.

Integration through Spring Cache annotations.

Common Cache Problems and Solutions

1. Data Consistency

In distributed environments, cache and database can diverge; strong consistency requires avoiding cache or employing update‑after‑write and retry mechanisms.

2. Cache Avalanche

If the cache server crashes, all requests fall back to the database, potentially overwhelming it. Mitigation includes high‑availability setups (master‑slave + Sentinel), local Ehcache, rate limiting, and graceful degradation.

3. Cache Penetration

Requests for non‑existent keys bypass cache and hit the database. Solutions include request validation, blacklisting invalid IDs, and using Bloom filters.

4. Cache Breakdown

When a hot key expires, a surge of requests can hit the database. Strategies depend on data volatility: never expire hot data, use distributed locks for refresh, or pre‑warm caches before expiry.

Why Redis Is Fast

HashMap‑like O(1) operations with in‑memory data.

Simple KV data structures.

Single‑threaded model eliminates lock contention.

Non‑blocking I/O with multiplexing.

Eviction Policies

volatile* – evicts only expired keys.

allkeys* – evicts any key.

LRU – least recently used.

LFU – least frequently used.

All trigger when memory usage reaches the configured threshold.

Persistence

RDB : snapshotting to a dump file at intervals.

AOF : appends every write command to a log file; default is RDB.

RDB offers faster recovery; AOF provides higher durability but may impact performance.

Master‑Slave Replication

Slave issues SLAVEOF [masterIP] [masterPort] to record master info.

Slave establishes a socket connection, exchanges PING/PONG, and receives a full data sync.

After initial sync, master streams write commands to slaves for consistency.

Sentinel Mode

Sentinel addresses the limitations of basic replication by providing monitoring, notification, automatic failover, and configuration provisioning.

Continuously checks health of master and slaves.

Sends alerts via API scripts.

Automatically promotes a slave to master on failure and reconfigures other slaves.

Clients obtain master address from Sentinel nodes.

The article also includes promotional messages and links for additional resources, interview questions, and community groups.