How to Safeguard Hot Data in High‑Concurrency Scenarios with Redis

The author, a front‑line R&D leader, frequently interviews candidates about high‑concurrency hot‑data availability and shares key techniques for ensuring stability.

3.1 Problem Background

When more than 10 million requests hit the backend simultaneously, if the cache is missing, expired, or fails, the traffic goes directly to the database, potentially causing a cascade or avalanche.

3.2 Various Business Scenarios and Solutions

3.2.1 Regular Hot‑Data Pre‑warming

For both aggregated and scattered hot keys that follow a predictable pattern, pre‑warming can keep them out of MySQL. Typical examples include dictionary‑type data such as product categories, brand types, discount rules in e‑commerce, or school, grade, class, subject data in education.

Usually, if the peak is at 10 am, the cache can be gradually built from 8 am to 10 am.

3.2.2 Irregular Hot‑Data Pre‑warming

Combine Redis with an application‑level detector to predict hot keys and pre‑warm them. Examples: Baidu real‑time hot search, Taobao product ranking.

3.2.3 Solving Uniform Expiration Issues

Cache keys may expire simultaneously during low‑traffic periods (e.g., night), causing a surge of cache creation in the next morning peak. Randomizing expiration times (e.g., n*3/4 + n*random()) spreads expirations over a range.

3.2.4 Filtering Garbage Requests

Typical flow is Get Key from cache, fall back to DB if missing, which can be abused. Validate the key format before querying the DB, or add a filter layer in the cache service. Reference: Redis series 16 – Bloom filter principles.

3.2.5 Message Queue and Spike‑Shaping

If the cache is missing and millions of requests arrive, queueing serializes the load, protecting the DB.

3.2.6 Appropriate Locking

Use distributed locks (SETNX) to ensure only one request populates the cache while others wait, reducing concurrent DB hits. Note that waiting can lower overall throughput.

3.2.7 Rate‑Limiting

Rate limiting at the service layer (Hystrix, Sentinel leaky‑bucket, Google RateLimiter token‑bucket) throttles excess traffic and triggers fallback logic to protect MySQL.

Sentinel leaky‑bucket diagram:

RateLimiter token‑bucket diagram:

3.2.8 Fallback Strategy (Backup Cache)

Maintain primary‑backup cache replication; if the primary fails, read from the backup with slightly stale data, avoiding DB overload.

3.2.9 Client‑Side Cache

Redis 6.0 client‑side cache reduces load on the cache service but introduces some staleness.

3.2.10 Empty‑Value Fallback

When a cache miss triggers a flood of requests, returning an empty or default value temporarily prevents DB overload. Diagram shows the flow.

3.2.11 High‑Availability Cluster and Auto‑Scaling

Cluster mode with automatic scaling at service, cache, and data layers ensures elasticity and high availability.

3.2.12 Recovery After Avalanche

After a cache avalanche, fast data recovery is essential. Use tools such as RDB snapshots or AOF logs to restore cache without overloading the DB. References: Redis series – RDB snapshot; Redis stability – AOF log.