【面试真题拆解14】电商高并发场景下商品详情页系统设计

很多面试官早就对“Redis缓存、MySQL分库分表”这些东西形成免疫了，他们更想要听到的是一个完整的链路，比如从服务到数据、从接入到落地的全流程设计。

当时面试官问我：

一家电商公司，它主要是面向消费者的，公司的一些业务场景流量会很高，比如说展示商品的那个页面，它的流量就很高，假设现在由你来做这个系统，负责商品详情页的展示，你能从服务的层面，数据的层面等多个维度来设计一下，让它能够支持一个更高的查询能力。

场景梳理

业务背景电商商品详情页，面对百万级QPS的高并发流量（比如大促、爆款商品）。

核心需求

1. 性能：支持高并发查询，响应时间 < 100ms
2. 一致性：商品价格、库存、标题修改后，能及时更新
3. 高可用：服务挂了、Redis挂了，系统不崩
4. 可扩展：新增商品、新增规格，能快速接入

关键数据商品基本信息（标题、主图、详情图）、价格（实时/活动）、库存、规格参数、促销信息（优惠券/秒杀）、评价统计。

设计思路

以“多级缓存”为核心，配合“服务分层+数据分层+异步更新”，构建“读多写少”的高并发详情页系统。

系统架构

服务层面

采用前后端分离+网关层+服务分层架构：

商品详情页是典型的读多写少场景，考虑服务层本地缓存 + 分布式缓存。

采用Caffeine作为服务层本地缓存，缓存极热点商品（比如爆款商品），避免每次请求都走Redis，

采用Redis作为分布式缓存，作为核心缓存层，缓存所有商品的详情数据。

调用流程：

先查本地缓存（Caffeine），如果命中就直接返回；如果本地未命中，查 Redis，命中则写入本地缓存，返回；如果Redis 未命中，查数据库，查到则写入 Redis + 本地缓存，返回。

数据层面

商品数据分为3类，不同类型用不同策略：

缓存更新的原则：

为了避免高并发下的缓存不一致问题，采用的是先更新数据库，再删除缓存的方式。

高并发优化

1.热点数据预热

大促前，把热门商品（如销量TOP100）写入Redis和本地缓存。

1. 限流+熔断

对商品详情接口设置限流。

考虑使用服务熔断，当Redis/数据库不可用时，快速失败，避免系统雪崩。

或者考虑使用降级策略，当Redis挂了，降级到直接查数据库，如果数据库也挂了，降级返回默认商品信息。

1. 页面静态化

对于完全静态的商品（比如虚拟商品或者不参与促销的商品），生成静态HTML页面，直接存到CDN，这样的话用户请求直接由CDN返回，不经过任何服务。