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.
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/
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
