How JD.com Scaled Its Product Detail Page to Tens of Billions of Requests
During Double 11, JD.com’s product detail page handled tens of billions of requests without downtime by introducing a unified service architecture that consolidates promotion, inventory, recommendation, and other functions behind a single Nginx+Lua entry point, employing multi‑level caching, service isolation, and flexible degradation mechanisms.
Why a Unified Service Is Needed
The product detail page depends on many services; a single unified entry simplifies management, enables centralized monitoring, allows graceful degradation, reduces asynchronous requests, and moves business logic to the backend.
Overall Architecture
All requests first hit Nginx, which runs Lua for pre‑processing. If the request is invalid, it is rejected immediately. Otherwise, Nginx checks a local cache; on a hit, data is returned. If missed, a distributed Redis cluster is queried; a hit returns data. If still missed, Nginx forwards the request to Tomcat, writes the result asynchronously back to Redis, and returns the response.
The Redis cluster is deployed across data‑center rooms; data is written to a primary cluster and replicated to others, ensuring consistency without separate clusters per room.
Key Architectural Ideas and Summary
Two read‑service patterns
Local cache
Multi‑level cache
Unified entry / service closed‑loop
Access‑layer introduction
Frontend logic moved to backend
Frontend interface aggregation on server side
Service isolation
Two Read‑Service Patterns
1. Distributed Redis Read
Redis is deployed separately from Nginx; cross‑machine reads are possible but cross‑data‑center reads are avoided thanks to master‑slave replication. Suitable when performance requirements are moderate.
2. Local Redis Read
Nginx and Redis run on the same machine, eliminating cross‑machine/network latency. If the local Redis miss, the request falls back to Tomcat. This mode may be limited by TCP connections; using Unix domain sockets can mitigate the issue.
Local Cache
Nginx uses its shared dictionary (via HttpLuaModule) as a local in‑memory cache that survives reloads. Consistent hashing is used for load balancing and URL rewriting to improve hit rates.
Dimension‑based caching stores data such as merchant info, shop info, ratings, brand, and category. A 30‑minute local cache reduced request volume by roughly threefold.
Multi‑Level Cache
The unified service employs four cache layers:
Access‑layer local cache in Nginx for hot‑spot protection.
Distributed Redis clusters per data‑center for large‑scale discrete data.
Tomcat’s local heap cache for frequently accessed small data (e.g., categories, brands).
Main Redis cluster as a safety net when all upper layers miss, protecting backend services from traffic spikes.
Unified Entry / Service Closed‑Loop
All core interfaces of the product detail page are routed through the unified service, either by querying databases/caches with business logic or by simple proxying and monitoring.
Introducing the Nginx Access Layer
The access layer performs pre‑validation, caching, business‑logic handling, degradation switches, AB testing, gray releases, monitoring, and rate limiting.
Data validation/filtering before forwarding to backend.
Cache pre‑position using Nginx shared dict and Lua.
Business logic moved to Lua for fast, zero‑downtime updates.
Granular degradation switches (global vs. atomic, access‑layer vs. backend).
AB testing via Lua‑controlled upstream selection.
Gray release/traffic switching through configurable upstream groups.
Monitoring of status, request_time, response_time.
Rate limiting per IP or per logged‑in user; optional request sleeping.
Frontend Business Logic Post‑Position
Frontend JavaScript is kept thin; most logic is performed on the server so that updates can be deployed in seconds without CDN cache delays.
Frontend Interface Server Aggregation
Multiple backend services (e.g., promotion, inventory, recommendation) are aggregated in the access layer using Lua coroutines, exposing a single API to the frontend. Example: a single request to
http://c.3.cn/recommend?methods=accessories,suit,combination&sku=1159330&cat=6728,6740,12408&lid=1&lim=6returns combined recommendation data.
Service Isolation
Isolation is achieved through thread‑pool segregation (Servlet 3 async), deployment/group segregation, and splitting high‑traffic services into separate applications.
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.
21CTO
21CTO (21CTO.com) offers developers community, training, and services, making it your go‑to learning and service platform.
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.
