Mastering Redis: Core Features, Caching Strategies, and High Availability

Introduction to Redis

Redis is an open‑source, high‑performance, in‑memory key‑value store written in C, used as a database, cache, and message broker, representing a NoSQL solution.

Redis Features

It offers excellent performance by storing data in memory, achieving up to 100,000 QPS.

Single‑threaded, single‑process model with thread safety via I/O multiplexing.

Can serve as a distributed lock.

Supports ten data types.

Provides data persistence.

It can also function as a message middleware with publish/subscribe capabilities.

Data Types

The following table illustrates the characteristics and typical use cases of five common data types:

Caching

Cache is the most important scenario for Redis. In Spring Boot, there are two typical usage patterns:

Directly using RedisTemplate.

Integrating Redis via Spring Cache annotations.

Problems When Using Cache

1) Data Consistency

In distributed environments, cache and database can easily become inconsistent; strong consistency requirements should avoid using cache.

Projects typically adopt strategies such as cache‑update mechanisms, updating the cache immediately after database writes, or adding retry logic on cache failures.

2) Cache Avalanche

A cache avalanche occurs when a cache node crashes, causing a sudden surge of requests to the database, which may become overloaded and fail.

To mitigate avalanches, consider measures before, during, and after incidents:

Before: Deploy Redis high‑availability solutions such as master‑slave with Sentinel or clustering.

During: Reduce database pressure with local Ehcache, rate limiting, and graceful degradation.

After: Enable Redis persistence to quickly recover data after a restart.

After redesign, a request first checks local Ehcache, then Redis, and finally the database, synchronizing data back to both caches.

Rate‑limiting component : Limits the number of requests per second, allowing excess requests to be degraded or return default values, as illustrated in the following diagram:

Database safety : Rate limiting prevents the database from crashing by controlling request throughput.

Partial request handling : With the database protected, roughly 40% of requests can still be processed.

During peak periods, some requests may be rejected, requiring users to retry.

Cache expiration times should be set flexibly per feature, e.g., setRedis(key, value, time+Math.random()*10000).

3) Cache Penetration

Cache penetration occurs when requests target keys that are absent in both cache and database, potentially overwhelming the database.

Mitigation strategies include:

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

Filter invalid IDs using a whitelist or store them in Redis for quick lookup.

Employ Bloom filters to efficiently test key existence before querying the database.

4) Cache Breakdown

Cache breakdown (or stampede) happens when a hot key expires, causing a flood of requests to hit the database simultaneously.

Solutions vary by data change frequency:

Data rarely changes : Set the hot key to never expire.

Data changes infrequently : Use distributed or local mutex locks to allow only one request to rebuild the cache.

Data changes frequently : Refresh the cache proactively with a background thread before expiration.

Why Redis Is So Fast

Redis can achieve over 100,000 QPS because it operates entirely in memory, uses a HashMap‑like O(1) lookup, employs a simple KV data model, runs single‑threaded to avoid lock contention, and utilizes non‑blocking I/O with multiplexing.

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 trigger when Redis memory usage reaches the configured threshold.

Redis Persistence

RDB

: Snapshotting – periodically writes the in‑memory dataset to a dump file. AOF: Append‑Only File – logs every write command; default is RDB, but both can be enabled for minimal data loss.

If occasional data loss of a few minutes is acceptable, RDB alone may suffice; however, AOF can impact performance due to heavy writes.

RDB snapshots facilitate backups and faster recovery compared to AOF.

Redis Master‑Slave Replication

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

Slave periodically discovers the master and establishes a socket connection.

Ping/Pong messages verify bidirectional communication.

Master sends the full dataset to the slave for initial synchronization.

After synchronization, the master continuously streams write commands to the slave to maintain consistency.

Redis Sentinel Mode

Issues with basic master‑slave replication include manual failover, limited write and storage capacity, and potential full‑sync pauses.

When the master fails, a slave must be manually promoted and clients reconfigured.

Write throughput is constrained by a single master.

Storage capacity is limited to a single node.

Replication interruptions may trigger full sync, causing noticeable latency.

Sentinel provides four key functions:

Monitoring: Continuously checks the health of master and slave instances.

Notification: Alerts administrators or applications via API when a server experiences issues.

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

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