Mastering Cache Strategies with Redis: From Theory to Practical Deployment

Preface

After stepping out of an air‑conditioned room into scorching heat, the need for cache warm‑up becomes evident.

Cache Theory

1. Suitable Scenarios for Caching

Caching stores frequently read data in memory to achieve speed, reducing reliance on relational databases. When read performance is insufficient, techniques like read replicas or sharding are used, but operations such as count(*) or complex joins still benefit from being cached to relieve database pressure.

2. Cache Penetration

Cache penetration occurs when a query misses the cache and falls back to the database, which can happen with crawlers requesting non‑existent pages or users searching for absent keywords. A common mitigation is to cache empty results with a short TTL and monitor suspicious IPs.

3. Cache Avalanche

A cache avalanche happens when many keys expire simultaneously, causing a sudden surge of database requests that can crash the system. Mitigation strategies include using dual keys with different expiration times, employing distributed locks, sending notification messages, or running a dedicated background thread to refresh caches.

4. Cache Naming and Expiration

Keys should be concise to save memory; a typical convention is SQL:1782 , where the prefix indicates the data source and the suffix is a hash of query parameters. Expiration times must align with business requirements—short for volatile data, longer for relatively static information.

5. Cache Warm‑up and Hotspot Management

When a system starts, traffic may overwhelm an empty cache. Warm‑up can be performed manually via the UI or automatically by a background thread that preloads hot data. In clustered caches, uneven distribution can create hotspots that risk another avalanche, so load balancing and monitoring are essential.

Redis Master‑Slave

Redis is an in‑memory key‑value store that can be used without persistence for caching. Running a master‑slave pair only requires the default configuration files, adjusting the bind address on the master and both bind and slaveof on the slave.

Testing Redis Availability

A test container runs a simple script that exits with code 0 on success and 1 on failure, enabling automated health checks. The script must be executed with host networking.

Further Optimizations

A single script can create master, slave, and test containers, distribute them across machines, and optionally deploy Sentinel for automatic failover or a Redis Cluster for sharding.

Operational Tips

When using config rewrite, SELinux may block file writes. With the noeviction policy, memory exhaustion triggers OOM; the default does not use LRU. Avoid the dangerous KEYS * command in production; use SCAN for paginated key inspection. For persistence, prefer BGSAVE or BGREWRITEAOF over SAVE, as they minimize service interruption despite a short fork overhead.