7、阿里P7面试官：双十一零点1亿人下单，你的购物车怎么设计不崩？
2026/1/3大约 9 分钟面试题面试题
想象一个场景：
- 1亿用户，在双十一零点前的60秒内，完成了最后一次购物车修改。
- 1000万次/秒的峰值写入请求（增、删、改）。
- 5000万次/秒的峰值读取请求（刷新购物车页面）。
如果让你来设计这个系统，你的第一反应是什么？
- 直接用MySQL？—— 你将在0.1秒内见证数据库从CPU飙升到彻底锁死，所有业务全面雪崩。
- 用Redis？—— 这是正确的方向，但如果你的回答仅限于此，那么在面试官眼中，你只触及了问题的冰山一角。
这道看似简单的“购物车设计题”，早已成为阿里、字节等大厂高阶面试的“分水岭”。它考察的从来不是单一的技术点，而是你在极端压力下，对性能、成本、一致性这“不可能三角”进行权衡的架构智慧。
今天，我将带你庖丁解牛，用“战场推演”的方式，让你不仅能给出满分答案，更能理解这背后的架构哲学。
冰与火之歌：购物车的极端冲突与面试官的真实意图
在双十一零点，购物车系统就像一个风暴眼，承受着冰与火的双重考验：
- 火焰：极度的写压力。 零点前的几分钟，是加购、改数量、删除的高峰期，写操作的洪峰甚至远超读操作。
- 冰山：非持久化需求。 在用户下单前，购物车里的所有数据本质上都是“临时的”。如果为了这堆临时数据，把宝贵的、昂贵的数据库资源耗尽，无异于“用航母来捕鱼”。
当面试官问出这个问题时，他内心真正担忧和考察的是：
- 存储模型的毁灭性打击： 你会不会无脑选择MySQL，然后被海量的写操作和行锁竞争，瞬间把数据库打崩？
- 缓存设计的简单化思维： 你会不会只想到“读缓存”，而忽略了购物车的“高频写”特性，从而在数据同步上设计出灾难性的方案？
- 业务流程的致命陷阱： 你有没有考虑过“未登录加购、登录后合并”这种场景？处理不好，用户数据丢失，客诉爆炸。
这些，才是藏在问题背后的真正杀机。现在，我们进入面试现场，逐一攻破面试官布下的技术陷阱。
第一关：你的数据“军火库”，建在哪？
面试官：“购物车的数据，你怎么存？”
❌ 踩坑回答：无脑MySQL
“在MySQL里建个购物车表，user_id加索引...” 如果你这么答，面试官的眉头已经皱起来了。
面试官追问：“双十一零点前一秒，一万个用户在修改自己的购物车，会发生什么？”
你必须精准回答：“会发生灾难性的行锁风暴。MySQL为了保证数据一致性，会对正在修改的行加锁。一万个并发修改，意味着大量的线程在等待锁释放，数据库CPU瞬间飙升，响应时间从毫秒变成秒级，最后整个数据库被拖垮，所有业务全部瘫痪。”
图示1：MySQL的行锁地狱
+--------------+ +--------------+ +--------------+
| 用户A修改 | | 用户B修改 | | 用户C修改 |
| 商品1 | | 商品2 | | 商品1 |
+--------------+ +--------------+ +--------------+
| | |
\__________________|__________________/
|
▼
+----------------+
| MySQL 数据库 |
| [表: cart] |
| 🔒行锁等待... | <-- 瓶颈爆发点
+----------------+✅ 满分回答：把主战场放在Redis！
“我们会将购物车数据完全托管在Redis中，MySQL只作为最终的持久化备份，甚至可以异步写入。”
面试官眼前一亮，追问：“Redis里，什么数据结构最合适？”
你自信地回答：“用 Hash。每个用户的购物车是一个独立的Hash。这种设计的精妙之处在于：”
- Key:
cart:user_id - Field:
product_id - Value: 商品信息的JSON字符串（包含数量、价格、sku等）
“这样，增加、删除、修改某个商品的数量，都变成了对一个Hash中单个Field的操作，时间复杂度是 O(1)，并且 互相独立，绝无锁竞争！”
图示2：Redis Hash的优雅结构
Key: "cart:10086"
+------------------+-------------------------------------------+
| Field | Value |
+------------------+-------------------------------------------+
| "product:88001" | "{'qty': 2, 'price': 99.0, 'name': '...'}" | <-- HSET
+------------------+-------------------------------------------+
| "product:88002" | "{'qty': 1, 'price': 199.0, 'name': '...'}"| <-- HINCRBY
+------------------+-------------------------------------------+
| "product:88003" | "{'qty': 5, 'price': 29.0, 'name': '...'}" | <-- HDEL
+------------------+-------------------------------------------+代码示例：用Java操作Redis Hash
// 假设使用Lettuce客户端，并注入了StatefulRedisConnection对象
public class ShoppingCartService {
private final ObjectMapper objectMapper = new ObjectMapper();
private final RedisCommands<String, String> redisCommands;
// 构造函数注入
public ShoppingCartService(StatefulRedisConnection<String, String> connection) {
this.redisCommands = connection.sync();
}
/**
* 添加或更新购物车中的商品（幂等操作）
*/
public void addOrUpdateProduct(String userId, String productId, int quantity) throws JsonProcessingException {
String cartKey = "cart:" + userId;
// 实际应从商品服务获取价格等实时信息
CartItem item = new CartItem(productId, quantity, 99.9);
// 使用HSET，将商品对象序列化为JSON字符串后存入Hash
redisCommands.hset(cartKey, productId, objectMapper.writeValueAsString(item));
}
/**
* 从购物车中移除商品
*/
public void removeProduct(String userId, String productId) {
String cartKey = "cart:" + userId;
// 使用HDEL，原子性删除Hash中的一个field
redisCommands.hdel(cartKey, productId);
}
}
// 商品信息DTO
class CartItem {
public String productId;
public int quantity;
public double price;
// ...构造函数、getter/setter省略
}第二关：我刚加的商品，刷新不能丢！怎么同步？
面试官：“只放Redis，万一断电，数据不就丢了？你怎么同步到数据库？”
❌ 踩坑回答：同步写
“每次操作Redis后，立刻写一次数据库。” 这相当于把MySQL的枷锁又戴回了Redis的头上，完全没有发挥出Redis的性能优势。
✅ 满分回答：性能优先，异步解耦
“针对购物车的场景，我们绝不采用同步写！而是采用异步写回（Write-Behind）的模式来应对‘高频写’的特性。”
“用户的操作只针对Redis，确保毫秒级响应。同时，我们会把这个‘变更事件’，扔进像Kafka或RocketMQ这样的消息队列里。然后由一个独立的后台消费服务，慢慢地、批量地把这些数据写回MySQL。这样，前端用户的体验和后端的数据落地就完全解耦了！”
图示3：异步写回架构
+-----------+ 1.操作Redis(极快) +-------------+
| 用户操作 | ------------------> | Redis (Hash)|
+-----------+ +-------------+
|
| 2.发送消息(瞬间)
▼
+----------------+
| 消息队列(Kafka)|
+----------------+
|
| 3.后台服务消费(异步/批量)
▼
+-----------+ 4.写入DB(无压力) +-------------+
| 消费服务 | ------------------> | MySQL |
+-----------+ +-------------+代码示例：发送异步消息
// 延续上面的Service
public class ShoppingCartService {
// 注入Kafka的Producer
private final KafkaProducer<String, String> kafkaProducer;
public void addOrUpdateProduct(String userId, String productId, int quantity) throws JsonProcessingException {
// ... (同上: 创建item, 序列化)
String cartKey = "cart:" + userId;
CartItem item = new CartItem(productId, quantity, 99.9);
String itemJson = objectMapper.writeValueAsString(item);
// 1. 操作Redis (主流程)
redisCommands.hset(cartKey, productId, itemJson);
// 2. 发送消息到Kafka (解耦流程)
// 消息体可以是包含所有必要信息的JSON
CartChangeEvent event = new CartChangeEvent("UPDATE", userId, item);
String eventJson = objectMapper.writeValueAsString(event);
// 发送过程是异步的，不会阻塞当前用户线程
kafkaProducer.send(new ProducerRecord<>("cart_events", userId, eventJson));
}
}
// 变更事件DTO
class CartChangeEvent {
public String type; // "UPDATE", "DELETE"
public String userId;
public CartItem item;
// ...
}第三关：我用游客身份加了3件，登录后怎么合并？
面试官：“这是一个非常经典的场景，处理不好，用户数据就乱了。”
✅ 满分回答：在Redis内完成原子化合并
“这个流程可以在Redis层面，对用户透明且高效地完成。”
- 游客状态： 用户访问时，我们生成一个唯一的
guest_id（存在Cookie或LocalStorage里），购物车Key为cart:guest_xyz。 - 登录时刻： 用户登录成功，我们拿到他的
user_id。 - 开始合并： 后端服务执行一个Lua脚本（保证原子性），或者在业务代码中执行以下逻辑：
- 获取
cart:guest_xyz中的所有商品。 - 遍历这些商品，逐一合并到
cart:user_123中。如果已有同款，则数量相加。 - 删除
cart:guest_xyz。
- 整个过程在Redis内存中完成，速度飞快，避免了复杂的数据库事务。
图示4：登录合并流程
-- 合并前 --
Key: "cart:guest_xyz" -> {p1: 1, p2: 2}
Key: "cart:user_123" -> {p2: 3, p3: 1}
||
▼ 用户登录...
||
-- 合并后 --
Key: "cart:user_123" -> {p1: 1, p2: 5, p3: 1} <-- 数量自动合并
Key: "cart:guest_xyz" -> (已删除)代码示例：Java实现合并逻辑
public class CartMergeService {
// ... 注入RedisCommands 和 ObjectMapper
public void mergeCart(String guestId, String userId) throws IOException {
String guestCartKey = "cart:" + guestId;
String userCartKey = "cart:" + userId;
// 1. 获取游客购物车的所有商品
Map<String, String> guestItems = redisCommands.hgetAll(guestCartKey);
if (guestItems.isEmpty()) {
return; // 游客购物车为空，无需合并
}
// 2. 遍历游客购物车，合并到用户购物车
for (Map.Entry<String, String> entry : guestItems.entrySet()) {
String productId = entry.getKey();
CartItem guestItem = objectMapper.readValue(entry.getValue(), CartItem.class);
// 检查用户购物车是否已有同款商品
String userItemJson = redisCommands.hget(userCartKey, productId);
if (userItemJson != null) {
// 如果有，则合并数量
CartItem userItem = objectMapper.readValue(userItemJson, CartItem.class);
userItem.quantity += guestItem.quantity;
redisCommands.hset(userCartKey, productId, objectMapper.writeValueAsString(userItem));
} else {
// 如果没有，则直接添加
redisCommands.hset(userCartKey, productId, objectMapper.writeValueAsString(guestItem));
}
}
// 3. 删除游客购物车
redisCommands.del(guestCartKey);
}
}完美收官：你的购物车架构蓝图
最后，向面试官清晰地总结你的答案：
“面试官您好，综上，我的高并发购物车设计核心如下：”
- 存储核心： Redis为主战场，MySQL为持久化备份，彻底分离实时计算和持久化存储。
- 数据模型： 采用Redis的 Hash 结构，实现O(1)复杂度的单品操作，避免锁竞争。
- 一致性策略： 采用异步写回模式，通过消息队列解耦，最大化保证前端性能。
- 业务健壮性： 通过服务端逻辑，在Redis内完成游客与登录用户的购物车原子化合并，保证数据无缝衔接。
“这套架构，能在保证用户极致体验的前提下，轻松应对双十一级别的并发挑战。”