Redis Cache Update Strategies and Best Practices

The author shares practical experiences and solutions encountered while using Redis, focusing on cache update challenges and advanced techniques.

Cache update types

[Proactive] Requires manual operation or scheduled tasks. [Passive] Triggered by user requests. [Pre‑load] Load data into cache ahead of time.

Solution 1 (Proactive)

Backend clicks a button, fetches the latest data from the DB, deletes the old cache, and stores the new data.

Problem: If a request queries the cache while it is being deleted, an empty result is returned, harming user experience.

Solution 2 (Passive)

When the frontend finds no cache, it reads from the DB and writes the data to the cache.

Problem: Concurrent requests that miss the cache cause multiple DB queries, leading to a thundering‑herd effect.

Solution 3 (Proactive without deletion)

The backend fetches the latest data but does not delete the cache; it overwrites existing entries and removes invalid ones.

Problem: The logic is complex and not easily reusable across different scenarios.

Recommended approach – Solution 4 (Pre‑load with versioned keys)

The author proposes a pre‑load method: load new data into a separate cache key, then switch the visible key to the new version and set the old version to expire.

Implementation details:

Two pieces of data are needed: ShowingKey: a key that points to the current version (e.g., a timestamp). Cache: the actual data stored under a versioned key.

Example for caching today’s new products:

Data cache key: Goods:Todays:{timestamp} (hash storing product info).

Showing key: Goods:Todays:ing whose value is the latest timestamp.

Update workflow

When an admin finishes editing, they click the update button, obtain the current server time (e.g., 1469938351000) as the new timestamp, write the DB data to Goods:Todays:1469938351000, then read the previous timestamp from Goods:Todays:ing, replace its value with the new timestamp, and set the old version’s key to expire (commonly after 5 seconds) to avoid deleting data still in use.

Update summary

Solution 1 degrades user experience and is not recommended.

Solution 2 can be improved with a program lock to avoid concurrent DB queries.

Solution 3 avoids the first two problems but adds complex logic and limited reusability.

Solution 4 (pre‑load with versioned keys) solves the issues of the previous three approaches.

Memory shortage and misuse

Problems: data accumulation without cleanup, storing unused fields, and retaining cold data.

Solutions: set expiration times based on validity, clean cold data regularly, and simplify key and field naming.

Key naming guidelines

Keep key length short to conserve memory.

Follow consistent case conventions.

Use business‑specific prefixes for related keys.

Other experiences

Concurrent increments using GET + SET can cause inaccurate counts; use Redis INCR for atomic increments.

ServiceStack 3.9.71.0 has an issue where SetEntryInHash returns true only on the first insertion; subsequent updates incorrectly return false, as demonstrated by hset returning 1 for a new field and 0 for an existing field.

The article ends with a note that the content is sourced from the internet and the original author holds the copyright.