Mastering Cache: Benefits, Strategies, and Optimization Techniques

1) Cache Benefits and Cost Analysis

Cache can effectively speed up application read/write operations and lower backend load, making it essential for daily development.

Typical architecture comparison:

Benefits:

Accelerated read/write: in‑memory cache (e.g., Redis) speeds up access compared to storage layers like MySQL.

Reduced backend load: fewer requests and complex SQL calculations.

Costs:

Data inconsistency: a time window between cache and storage updates.

Code maintenance overhead: handling both cache and storage logic.

Operational cost: e.g., managing a Redis Cluster.

Typical use cases:

Heavy computation scenarios (complex joins, aggregations).

Accelerating request response even for simple queries like select*from table where id=.

2) Cache Update Strategies

Because cached data may become stale, various update strategies are needed.

LRU/LFU/FIFO eviction : used when cache exceeds its memory limit (e.g., Redis maxmemory-policy).

Timeout eviction : set expiration time; after expiry, data is fetched from storage and re‑cached.

Proactive update : notify cache immediately after source data changes (e.g., via message queues).

Recommendations:

Low‑consistency services: configure max memory and eviction policy.

High‑consistency services: combine timeout eviction with proactive updates.

3) Cache Granularity Control

Improper granularity wastes space, bandwidth, and hampers code reuse. Choose granularity based on data generality, space usage, and maintainability.

Typical stack: Redis as cache layer, MySQL as storage layer.

4) Penetration Optimization

Cache penetration occurs when queries for non‑existent data miss both cache and storage. Solutions:

Cache empty objects : store a placeholder with a short TTL to prevent repeated storage hits.

Bloom filter interception : maintain a Bloom filter of existing keys to filter out impossible queries before hitting storage.

Bloom filter principle: multiple hash functions map an element to K bits; if any bit is 0, the element is definitely absent; if all are 1, it is probably present.

5) Bottom‑Hole (Scalability) Optimization

Adding more cache nodes does not always improve performance; distributed batch operations can become a bottleneck.

IO optimization ideas:

Command optimization (e.g., better SQL).

Reduce network round‑trips.

Lower connection cost (persistent connections, connection pools, NIO).

Four batch‑operation approaches in Redis Cluster:

Serial commands : execute N individual GETs (high network cost).

Serial IO : group keys by node, then use MGET or pipeline per node (network cost = number of nodes).

Parallel IO : same as serial IO but multithreaded; network cost remains node count, but latency becomes O(1). O(1) hash_tag : force related keys onto the same node, achieving one network round‑trip.

6) Avalanche Optimization

Cache avalanche happens when the cache becomes unavailable, causing a sudden surge of traffic to the storage layer and potentially cascading failures.

Prevention measures:

Ensure high availability of the cache layer (e.g., Redis Sentinel, Redis Cluster).

Isolate resources and apply rate‑limiting and degradation for critical backends.

Conduct failure‑drill exercises before production launch.

7) Hot‑Key Rebuild Optimization

When a hot key expires, many threads may simultaneously rebuild it, overwhelming the backend.

Goals: reduce rebuild frequency, keep data as consistent as possible, minimize risk.

Mutex lock : allow only one thread to rebuild using Redis SETNX; others wait and retry.

Never‑expire : keep the key physically permanent and apply a logical expiration, rebuilding in a background thread.

Implementation steps:

Try to get the value from Redis; if present, return it.

If missing, attempt SETNX with an expiration; if successful, build the cache.

If SETNX fails, sleep briefly (e.g., 50 ms) and retry until the value appears.

Both methods effectively mitigate hot‑key problems, though the “never‑expire” approach may temporarily introduce stale data.

Author: 不行就改名