Redis Overview: Features, Data Types, Caching Strategies, Performance, Eviction Policies, Persistence, Replication, and Sentinel

1. Redis Introduction

Redis is an open‑source high‑performance in‑memory key‑value store written in C. It can be used as a database, cache, message broker, and is a NoSQL (non‑relational) database.

2. Redis Features

Excellent performance: data stored in memory, read/write speed is very fast, supporting up to 100,000 QPS.

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

Can be used as a distributed lock.

Supports five data types.

Supports data persistence to disk.

Can serve as a message broker with publish/subscribe.

3. Data Types

The following table (image below) lists the five data types, their characteristics, and typical use cases.

4. Caching

Data caching is the most important scenario for Redis. In Spring Boot, there are two common ways to use it:

Directly using RedisTemplate .

Integrating Redis via Spring Cache annotations.

5. Problems When Using Cache

(1) Data Consistency

In distributed environments, cache and database can easily become inconsistent. If strong consistency is required, avoid using cache. Instead, adopt strategies such as cache‑update after database write, or retry mechanisms on cache failure.

(2) Cache Avalanche

A cache avalanche occurs when the cache node crashes, causing all requests to hit the database, which may become overloaded and fail. Solutions are divided into three phases:

Before incident: use high‑availability Redis (master‑slave + Sentinel, cluster) to avoid total failure.

During incident: reduce database pressure with local Ehcache, rate limiting, and degradation.

After incident: enable Redis persistence so that after a restart data can be quickly restored from disk.

The revised data flow first checks local Ehcache, then Redis, and finally the database, synchronizing the result back to both caches.

Rate‑limiting components can cap the number of requests per second, allowing excess requests to be degraded or return default values.

(3) Cache Penetration

Cache penetration happens when requests for non‑existent keys bypass the cache and hit the database repeatedly, potentially causing a crash. Mitigation methods include:

Validate requests at the API layer (authentication, parameter checks) and reject illegal ones.

Use a Bloom filter or a dedicated Redis key to quickly determine non‑existence.

(4) Cache Breakdown (Stampede)

When a hot key expires, a massive number of requests may simultaneously query the database, overwhelming it. Solutions vary by data change frequency:

If data rarely changes, set the key to never expire.

If updates are infrequent, use distributed or local mutexes to allow only one request to rebuild the cache.

If updates are frequent, employ a background thread to proactively refresh or extend the expiration before it expires.

6. Why Redis Is So Fast

Uses a HashMap‑like structure with O(1) time complexity for most operations, all in memory.

Simple KV data model and straightforward data structures.

Single‑threaded design eliminates lock contention and context switches.

Non‑blocking I/O with multiplexing.

7. Redis Eviction Policies

Policies prefixed with volatile evict only expired keys.

Policies prefixed with allkeys consider all keys.

LRU (Least Recently Used).

LFU (Least Frequently Used).

All policies trigger when Redis memory usage reaches the configured threshold.

8. Redis Persistence

Redis provides two persistence mechanisms:

RDB : Snapshotting the in‑memory data to a dump file at intervals.

AOF : Appending every write command to a log file. By default Redis uses RDB.

If occasional data loss of a few minutes is acceptable, RDB alone may suffice. AOF offers finer durability but can impact performance. Redis can enable both; on restart it prefers AOF for recovery, minimizing data loss.

9. Master‑Slave Replication

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

Slave discovers master, establishes a socket connection.

Slave sends Ping, master replies Pong to confirm communication.

After connection, master sends full data to slave for synchronization.

Subsequently, master streams write commands to slaves to keep data consistent.

10. Redis Sentinel Mode

Traditional master‑slave replication has drawbacks: manual failover, limited write and storage capacity, and potential full‑sync pauses.

Sentinel provides a high‑availability architecture (image below) that performs four main tasks:

Monitoring : Continuously checks health of master and slaves.

Notification : Sends alerts via API scripts when a Redis instance fails.

Automatic Failover : Promotes a slave to master and re‑points other slaves without human intervention.

Configuration Provider : Clients query Sentinel nodes to obtain current master address.