Operations 8 min read

Distributed Cache Strategies for High‑Traffic Flash‑Sale Scenarios

The article reviews a 2014 Double‑11 flash‑sale caching solution, analyzing traffic spikes, evaluating scaling versus caching approaches, and proposing a sentinel‑based distributed cache that pre‑emptively refreshes data to avoid cache penetration and ensure high‑concurrency reliability.

Architect
Architect
Architect
Distributed Cache Strategies for High‑Traffic Flash‑Sale Scenarios

Scenario Introduction:

During a large promotion, certain products are sold in flash‑sale events with traffic expected to exceed normal peak by more than 5+倍. The product calculation logic is complex, requiring billions of dynamic condition evaluations, with constantly changing inventory and attributes.

Brainstorming

Two main directions are considered: 扩容 (scaling) and 缓存 (caching).

Scaling

Scaling is straightforward if the application is stateless, but stateful services incur additional operational cost and post‑event resource waste.

Caching

Caching can be applied at various granularities. Static page caching is unsuitable because each user sees different product data. Caching intermediate results on the front‑end machines is explored.

Cache Intermediate Results

Simple cache‑then‑fetch approach fails for flash sales due to cache penetration. Real‑time cache with asynchronous updates avoids penetration but suffers from missing data for the first batch of requests.

Why Not Pre‑initialize Cache?

Pre‑populating the cache is impractical due to the massive key space and the load it would place on backend services.

Cache Invalidation

Both simple and real‑time caches face challenges when the cache expires, leading to first‑batch request issues.

Cache Update Concurrency

Distributed cache updates encounter concurrency problems; a distributed lock or a sentinel thread can mitigate this.

Better Cache Approach

A sentinel thread is introduced: the first request becomes the sentinel, fetching data from the backend and updating the cache while other requests wait. The sentinel wakes slightly before cache expiry to refresh data, ensuring the cache never appears stale.

Implementation Details

The sentinel can be implemented using an atomic counter (e.g., Redis or Tair). When a request finds a missing cache entry, it increments the counter; the thread that sees the counter value of 1 becomes the sentinel. Other threads spin‑wait with a timeout.

Original article link: http://blog.lichengwu.cn/architecture/2015/06/14/distributed-cache/

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

BackendDistributed Systemssentinelflash sale
Architect
Written by

Architect

Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.