阿里系统设计面试全流程：设计淘宝购物车系统的完整复盘

阿里系统设计面试全流程：设计淘宝购物车系统的完整复盘

背景介绍

我是2024年4月面的阿里，岗位是Java后端开发，4年经验。说实话，阿里的系统设计面是我经历过的最硬核的一场——面试官不只是让你画架构图，而是会追问到数据库表设计、分布式事务、缓存一致性这些非常具体的层面。我面的这个组是淘宝交易核心团队，所以面试官直接让我设计淘宝的购物车系统。这个题目看起来简单，但深挖下去涉及到的技术点非常多：高并发读写、数据一致性、分布式锁、缓存策略、消息队列……我当时大概讲了40分钟，中间被追问了不下20次。下面是完整的复盘。

面试流程复盘

面试官是一位P8级别的技术专家，自我介绍说是淘宝交易架构组的。整个面试55分钟，节奏非常紧凑，几乎没有喘息的时间。

前3分钟：面试官简单介绍了面试流程，然后直接出题："请你设计一个类似淘宝购物车的系统。"我按照惯例先做需求澄清。

3-12分钟：需求澄清阶段。我问了以下关键问题：

1. 用户规模？——"假设日活2亿，大促期间QPS可达50万。"

2. 购物车容量？——"单个用户最多120个商品。"

3. 核心功能？——"加购、修改数量、删除、选中/取消选中、合并购物车。"

4. 一致性要求？——"最终一致性即可，不要求强一致。"

5. 多端同步？——"需要支持PC、APP、小程序多端同步。"

面试官对我问的这些问题表示认可，说"需求理解得不错，开始设计吧"。

12-40分钟：这是最核心的环节，我按照存储设计→缓存设计→核心流程→高并发优化→扩展方案的顺序来讲解。面试官在每个环节都追问了非常具体的问题，有些我回答得比较流畅，有些则被追问到词穷。

40-50分钟：面试官开始追问大促场景下的特殊处理，比如"双11期间购物车QPS暴增100倍怎么办？""购物车数据怎么和库存系统联动？""购物车价格怎么实时更新？"

最后5分钟：面试官让我问问题，我问了团队的技术挑战和购物车系统的下一步演进方向。

真题详解：设计淘宝购物车系统

一、存储设计

购物车的存储是整个系统的基础，我设计了MySQL+Redis双存储方案：

1. MySQL主存储：购物车表设计——user_id（用户ID）、item_id（商品ID）、sku_id（SKU ID）、quantity（数量）、checked（是否选中）、create_time、update_time。核心索引：(user_id, item_id, sku_id)联合唯一索引。

面试官追问"为什么用MySQL而不是纯Redis？"——我回答：1. Redis数据不能持久化保证不丢失，购物车数据是用户资产，不能接受丢失；2. MySQL支持复杂查询（如按店铺分组），Redis需要多次查询组装；3. MySQL可以做数据分析和对账。

面试官继续追问"那为什么不全用MySQL？"——因为MySQL的读写性能不足以支撑50万QPS，需要Redis做缓存加速。

2. Redis缓存：用Hash结构存储，key为cart:{user_id}，field为item_id:sku_id，value为JSON（包含quantity、checked等）。这样一次HGETALL就能获取用户整个购物车，比String结构逐个GET高效得多。

面试官追问"为什么用Hash而不是String？"——String结构每个商品一个key，获取整个购物车需要MGET，key数量多时性能差。Hash一次HGETALL搞定，且支持HINCRBY原子增减数量。

二、缓存策略设计

缓存策略是购物车系统最核心的设计之一，我讲了读写策略和一致性保障：

1. 写策略：Write-Behind + 异步落库。用户加购时先写Redis，然后异步写MySQL。面试官追问"异步写MySQL失败了怎么办？"——我回答：1. 写MySQL失败会重试3次；2. 3次都失败则写入死信队列，人工处理；3. Redis和MySQL之间有定时对账任务，每5分钟跑一次，发现不一致则修复。

面试官继续追问"对账期间用户读到不一致的数据怎么办？"——我承认这是一个trade-off，购物车场景可以接受短暂的不一致，因为购物车是辅助决策工具，不是交易系统。最终下单时会从库存系统和价格系统实时获取最新数据，购物车中的数据仅供参考。

2. 读策略：Cache-Aside。读购物车时先查Redis，命中则返回；未命中则查MySQL并回写Redis，设置7天过期时间。

3. 缓存击穿防护：热点用户的购物车用互斥锁防止并发回源。面试官追问"互斥锁怎么实现？"——用Redis的SETNX，获取锁的线程查MySQL并回写，其他线程等待后重试Redis。

三、核心流程设计

1. 加购流程：

用户点击加购→网关鉴权→购物车服务→检查商品有效性（调用商品服务）→检查库存（调用库存服务）→写入Redis（HSET）→发送MQ消息→异步写入MySQL→返回成功。

面试官追问"检查商品有效性和库存会不会拖慢加购速度？"——确实会，所以我把这两个检查做成了异步预检：加购时不检查，直接写入购物车，然后异步检查。如果商品无效或库存不足，标记该商品为"无效状态"，用户打开购物车时看到灰色提示。这样加购接口的RT从200ms降到了20ms。

面试官追问"用户加了无效商品会不会投诉？"——我们在购物车页面会明确提示"该商品已下架"或"库存不足"，用户可以理解。而且大部分用户加购后不会立即下单，等他们打开购物车时异步检查已经完成，状态是最新的。

2. 修改数量流程：

用户修改数量→购物车服务→Redis HINCRBY原子增减→发送MQ消息→异步更新MySQL。关键点：HINCRBY是原子操作，不需要加分布式锁。

面试官追问"如果用户快速连续点击+1，会不会出现数量不一致？"——不会，因为HINCRBY是原子操作，每次+1都会正确累加。但MQ消息可能乱序，所以MySQL更新时用quantity的绝对值而不是增量。

3. 合并购物车流程：

用户未登录时购物车数据存在本地（Cookie/LocalStorage），登录后需要合并到服务端。合并策略：本地购物车逐个与服务端比对，服务端已有的则数量取较大值，服务端没有的则新增。

面试官追问"合并时并发冲突怎么处理？"——用分布式锁（Redis SETNX）锁定用户的购物车，合并期间其他加购请求排队等待。锁的超时时间设为5秒，防止死锁。

四、高并发优化

1. 热点用户分片：大促期间，某些头部用户的购物车访问量极高（如主播带货场景）。解决方案：将这些用户的购物车数据本地缓存一份，读请求优先走本地缓存，写请求同时更新本地缓存和Redis。

2. 批量操作优化：用户全选/取消全选时，不要逐个更新Redis，而是用Pipeline批量执行，RT从N次网络往返降到1次。

3. 限流降级：大促期间购物车QPS暴增，用令牌桶限流，超限请求返回"系统繁忙"。降级策略：关闭非核心功能（如购物车推荐、凑单提示），只保留核心的加购、查看、删除功能。

4. 数据分片：MySQL按user_id分库分表，每个库8个表，共16个库128个表。Redis Cluster按user_id的哈希值分配slot。

五、大促场景特殊处理

面试官特别追问了双11场景下的处理：

1. 购物车与库存联动：用户加购时只是"意向"，不锁定库存。下单时才真正扣减库存。面试官追问"那购物车显示的库存是实时的吗？"——不是，购物车显示的库存是准实时的，每5分钟从库存系统同步一次。如果用户下单时库存不足，会提示"库存已售罄"。

2. 价格实时更新：购物车中的商品价格需要实时反映促销活动。方案：购物车服务订阅价格变更消息（通过MQ），收到后更新Redis中的价格。面试官追问"如果MQ消息延迟了怎么办？"——用户打开购物车时，前端会调用价格服务获取最新价格，作为兜底方案。

3. 购物车预热：双11前1小时，把活跃用户的购物车数据从MySQL预加载到Redis，避免大促开始时大量缓存未命中导致MySQL被打崩。

六、扩展方案

1. 多端同步：用MQ广播购物车变更事件，各端收到后刷新本地缓存。面试官追问"如果用户同时在不同端修改购物车怎么办？"——以最后写入为准（Last Write Wins），因为购物车场景下冲突概率极低，且冲突的影响有限。

2. 购物车推荐：基于购物车中的商品推荐关联商品。方案：购物车服务调用推荐服务，推荐服务根据购物车商品的特征向量做相似推荐。

3. 购物车分享：生成购物车快照，分享给好友。方案：购物车数据序列化为JSON，存入MongoDB，生成分享链接。

心得建议

1. 购物车系统的核心是缓存策略，面试官一定会追问Redis和MySQL的一致性问题。一定要想清楚写策略（同步写Redis+异步写MySQL）和对账方案。

2. 不要忽略大促场景，阿里面试官特别爱问"双11怎么办"。提前准备预热、限流、降级方案。

3. 存储选型要说清楚理由，为什么用MySQL+Redis双存储？为什么用Hash不用String？每个选型都要有理有据。

4. 主动讨论trade-off，比如"购物车数据允许短暂不一致，因为下单时会实时校验"，这种表述非常加分。

5. 准备数据库表设计，阿里面试官可能会让你画ER图或写建表SQL。购物车表的索引设计、分库分表策略都要提前想好。

FAQ

Q：阿里的系统设计面和字节的有什么区别？

A：阿里更偏工程落地，会追问到数据库表设计、分布式事务、缓存一致性这些非常具体的层面。字节更偏架构思路，关注你分析问题的框架和trade-off的讨论。

Q：购物车系统的数据量有多大？

A：2亿用户，平均每人20个商品，总数据量约40亿条。MySQL分库分表后单表约3000万条，在合理范围内。

Q：没有电商经验怎么办？

A：购物车系统的设计思路是通用的：存储选型→缓存策略→核心流程→高并发优化→扩展方案。你可以类比其他场景（如收藏夹、待办事项）来讲解。