How to Tackle Hotspot Key Bottlenecks in High‑Traffic Systems

Causes of Hotspot Key Issues

1. User consumption data far exceeds production data, such as during flash sales, trending news, popular comments, or celebrity live streams, leading to massive request spikes on a single key.

2. Request shards concentrate on a single server, exceeding its performance limits when many threads access the same key.

Impact of Hotspot Keys

Hotspot keys can cause traffic to concentrate and hit physical NIC limits, overwhelm cache shard services, and ultimately breach the database, triggering a cascade of failures and service outages.

Mitigation Strategies

1. Server‑Side Cache

The server maintains an LRU‑based local cache. When the server is overloaded it returns responses directly without forwarding to the DB; only when the server is healthy does it query the DB and refresh the cache.

Drawbacks include cache invalidation challenges, multi‑thread cache construction, and potential dirty reads.

2. Memcache/Redis Deployment

Clients access a dedicated cache layer before reaching the DB, offering low latency and no bandwidth limits, but it can waste memory and still suffer from dirty‑read issues.

3. Local Cache on Clients

Requires prior knowledge of hotspot keys and suffers from limited capacity, consistency lag, and possible omission of hot keys.

4. Read/Write Separation

Architecture includes SLB for load balancing, a Proxy layer for routing, Master for writes, ReadOnly nodes for reads, and Slave nodes for high availability. Write requests go to Master, reads to ReadOnly, allowing horizontal scaling of read traffic.

5. Hotspot Data Solution

Proactively discovers hot keys and stores them in a Proxy‑level LRU cache while the DB periodically computes hotspot sets. This approach scales read capacity, is transparent to clients, and reduces DB load.

Hotspot handling involves two phases: writing the key through SLB to a Proxy which stores it in Redis, and reading it directly from the Proxy cache if identified as hot, leveraging horizontal scaling of Proxy nodes.

Hotspot discovery runs periodic statistics on key request volumes, flags keys exceeding thresholds, and maintains a small LRU list for fast lookup. DB‑side calculations use threshold‑based, period‑based, and version‑based methods with minimal performance and memory overhead.

Comparison

All presented solutions improve upon traditional methods by offering horizontal scalability, client transparency, and varying trade‑offs between consistency and cost. Read/write separation excels at handling massive hot data volumes, while Proxy‑based caching provides cost‑effective performance gains.