Comprehensive Guide to Cache Optimization and Design Strategies

1) Cache Benefits and Cost Analysis

Cache can dramatically accelerate read/write operations because it resides in memory, while traditional storage such as MySQL may become a bottleneck. It also reduces backend load by off‑loading frequent or complex queries. However, caching introduces data inconsistency windows, higher code‑maintenance effort, and additional operational overhead (e.g., managing a Redis Cluster).

2) Cache Update Strategies

Three main strategies are discussed:

LRU/LFU/FIFO eviction : Used when cache memory reaches a configured limit (e.g., Redis maxmemory-policy ).

TTL expiration : Assign an expiration time to keys; after expiry the data is fetched from the source and re‑cached.

Active update : Immediately refresh the cache after the underlying data changes, often via a message queue.

A comparison table (image) illustrates the trade‑offs.

3) Cache Granularity Control

Choosing the right cache granularity balances space usage, network bandwidth, and code maintainability. Typical stack: Redis for cache, MySQL for persistent storage.

4) Penetration Optimization

Cache penetration occurs when queries for non‑existent data miss both cache and storage. Solutions include caching empty objects with short TTLs and using a Bloom filter to pre‑filter impossible keys.

5) Bottom‑Hole (No‑Bottom) Optimization

When adding many cache nodes does not improve performance, batch‑operation latency can increase. Three optimization directions are suggested: command‑level tuning, reducing network round‑trips, and using connection pooling/NIO.

Four distributed batch‑operation patterns for Redis Cluster are compared:

Serial commands : One GET per key (high latency).

Serial I/O with slot grouping : Group keys by slot and use MGET or pipeline per node.

Parallel I/O : Same as serial I/O but executed concurrently (network time ≈ O(1)).

Hash‑tag routing : Force related keys onto the same node, reducing network calls to a single round‑trip.

6) Avalanche Optimization

A cache avalanche happens when the cache becomes unavailable and all traffic floods the backend. Mitigation includes ensuring high availability of the cache layer (e.g., Redis Sentinel/Cluster) and isolating backend resources with rate‑limiting and graceful degradation.

7) Hot‑Key Reconstruction Optimization

Hot keys can cause a thundering‑herd problem when they expire. Two approaches are described:

Mutex lock : Only one thread rebuilds the cache; others wait (example uses Redis SETNX with expiration).

Never‑expire with logical TTL : Physical key never expires; a logical expiration triggers background rebuild, accepting temporary inconsistency.

Code snippets illustrate the mutex lock implementation using SETNX and retry logic.

The article concludes with additional resources, community links, and a reminder that the content is for educational purposes.