How to Tackle Hotspot Key Bottlenecks in High‑Traffic Systems

Reasons for Hotspot Key Issues

1. User consumption data far exceeds production data (e.g., hot products, trending news, popular comments, celebrity live streams). When a single item receives tens of thousands of clicks or purchases, demand spikes and creates hotspot problems.

2. Request shards concentrate on a single server, exceeding its performance limits, leading to hotspot key issues.

Hazards of Hotspot Key Issues

Hotspot keys can cause traffic concentration that reaches physical NIC limits, overwhelm cache shard services, and cause database overloads, resulting in service avalanches.

Solutions

Typical solutions focus on client‑side and server‑side modifications.

1. Server‑side Cache Strategy

Server maintains an LRU‑based local cache. When the server is congested, it returns responses without forwarding to the DB; only when the server is free does it forward client requests to the DB and refresh the cache.

Cache invalidation and multi‑threaded cache construction issues

Cache loss and reconstruction problems

Dirty read issues

2. Memcache / Redis Approach

Deploy a dedicated cache on the client side. Clients first access the service layer, then the cache layer on the same host.

Memory resource waste

Dirty read issues

3. Local Cache Approach

Issues include the need to pre‑identify hotspots, limited cache capacity, growing inconsistency, and potential hotspot key omission.

4. Read‑Write Separation for Hot Reads

Architecture components:

SLB layer for load balancing

Proxy layer for automatic read‑write routing

Master handles write requests

ReadOnly nodes handle read requests

Slave nodes provide high availability with the Master

Clients send requests to SLB, which distributes them to multiple Proxies. Proxies route write requests to Master and read requests to ReadOnly nodes, allowing read‑only nodes to scale horizontally and effectively address hotspot reads.

5. Hotspot Data Solution

Proactively discover hotspots and store them. Clients access SLB, which forwards requests to Proxies; Proxies forward to backend Redis. Proxy adds a local LRU cache for hotspot data, while DB nodes compute hotspot data sets and feed them back to the Proxy.

Proxy local cache enables horizontal read scalability

DB nodes periodically compute hotspot data collections

DB feeds hotspot data to Proxy

Transparent to clients, no compatibility changes needed

Hotspot Key Handling

1. Hot Data Reading

When SLB receives a key K1, it writes it via a Proxy to Redis. If K1 becomes a hotspot, the Proxy caches it, allowing subsequent client accesses to bypass Redis.

Proxy’s horizontal scalability enhances hotspot data access capability.

2. Hot Data Discovery

DB periodically counts key requests; once a threshold is reached, hotspots are identified and placed in a small LRU list. Redis marks hotspots during access, and DB uses statistical thresholds, periodic cycles, and version‑based methods with minimal performance and memory impact.

Solution Comparison

Compared with traditional methods, both read‑write separation and hotspot data solutions offer flexible horizontal scaling, client transparency, and some data inconsistency, while read‑write separation stores larger volumes of hotspot data and Proxy‑based approaches have cost advantages.