一、前言

1.1 写作初衷

很多开发工程师眼里，购物车是电商中最简单、无技术含量的模块：无非就是增删改查、勾选商品、结算汇总。

但在亿级大促场景下，购物车是整个交易链路的流量入口、承上启下的核心枢纽：承接商品浏览、承接用户选品、前置价格校验、前置库存校验、预构建交易订单数据。

大促期间90%的交易前置流量，全部压在购物车服务上。

普通开发只会实现「功能可用」，架构师需要解决一系列生产级难题：

未登录游客加购、登录后数据合并、重复加购去重、多端数据同步、高并发加购不雪崩、购物车价格实时刷新、库存前置拦截、冷热数据分层、缓存一致性、海量用户购物车存储碾压问题。

线上大量诡异问题：用户购物车商品莫名消失、重复多出同款商品、价格结算和详情页不一致、登录后数据覆盖、大促加购超时、购物车脏数据堆积，根源全是购物车架构设计不规范。

本文基于前面的DDD分层架构、商品领域模型，完整落地企业级购物车架构，从零拆解建模、存储架构、核心流程、合并策略、高并发方案、踩坑复盘，彻底打通电商交易前置链路。

1.2 本文核心收益

读完本文，你将彻底掌握：

• 购物车中心DDD领域边界与核心职责，杜绝业务耦合

• 游客未登录购物车 + 登录用户购物车双模型架构

• 行业标准购物车合并策略（覆盖/合并/去重）落地细节

• 亿级用户下冷热数据分离、Redis+MySQL双存储架构

• 高并发加购、大促流量削峰、接口防抖、幂等设计

• 购物车实时价格、库存联动刷新机制

• 多端同步、脏数据清理、过期数据自动回收方案

• 购物车高频线上故障根治与大厂面试高分思路

1.3 前置回顾

上一篇我们完成了商品中心完整建模，吃透了SPU/SKU静态模型、类目属性、上下架高并发架构。购物车是商品静态数据 → 交易动态链路的第一站，所有下单行为都必须经过购物车前置校验，本文将补齐电商交易链路最关键的前置环节。

二、购物车DDD领域边界与核心认知

2.1 限界上下文定义

购物车领域核心职责：临时承载用户选品数据，维护用户预购商品集合，提供选品编辑、价格汇总、前置校验能力，为订单交易提供可信预数据，不负责交易、不负责库存落地、不负责资金结算。

一句话总结：购物车是临时预购容器，不是持久化交易容器。

2.2 领域红线边界（高频踩坑）

2.2.1 归属购物车领域

商品加购、删除、修改数量、勾选/取消勾选、购物车列表组装、未登录数据缓存、登录数据合并、购物车过期清理、选品数据聚合。

2.2.2 绝不归属购物车领域

• 商品价格计算、优惠叠加：归属营销价格引擎（购物车只做查询聚合，不计算）

• 真实库存扣减、锁定：归属库存领域（购物车仅做前置校验）

• 订单创建、支付、履约：归属订单交易领域

• 商品上下架状态变更：归属商品领域

架构核心原则：购物车只做「数据承载+前置校验+视图聚合」，所有核心业务计算全部外溢到对应领域，保证购物车服务极致轻薄、高可用、高并发。

三、购物车双模型架构设计（未登录 + 登录）

所有电商购物车架构，都绕不开一个核心难题：游客状态加购，登录后无缝合并。

绝大多数小厂架构直接粗暴覆盖数据，导致用户加购数据丢失、引发大量客诉。大厂采用游客临时购物车 + 用户正式购物车双模型架构。

3.1 未登录游客购物车（临时态）

3.1.1 核心特征

• 无用户ID，依托前端生成临时唯一标识（UUID）关联数据

• 数据只缓存Redis，不落地MySQL，减轻数据库压力

• 设置过期时间（默认7天），长期不登录自动销毁

• 仅支持加购、删除、改数量，不做复杂持久化

3.1.2 Redis存储结构设计

Key：cart:temp:{uuid}

Value：Hash结构，存储SKU-ID、数量、加购时间、是否勾选

设计优势：读写极速、无DB压力、过期自动清理、适配海量游客流量。

3.2 登录用户购物车（持久态）

3.2.1 核心特征

• 以user_id为唯一维度关联数据

• Redis缓存 + MySQL持久化双存储

• 支持多端同步、长期留存、编辑记录

• 支持冷热数据分层管理

3.2.2 Redis存储结构设计

Key：cart:user:{userId}

Hash结构存储全量购物车SKU数据，实现毫秒级查询。

四、核心难点：购物车合并策略（生产级标准）

用户从未登录状态切换为登录状态，必须触发购物车合并，这是面试必考、生产高频出问题的核心逻辑。

4.1 三种合并场景与取舍

4.1.1 场景一：游客有数据，用户无数据

策略：全部迁移，将游客临时购物车数据完整迁移至用户购物车，清空游客数据。

4.1.2 场景二：游客无数据，用户有数据

策略：保留原数据，无需任何操作，直接展示用户持久购物车。

4.1.3 场景三：游客、用户均有数据（核心难点）

行业统一标准合并规则：同SKU合并数量、以客户端最新数据为准，不同SKU全部保留，去重不覆盖

• 相同SKU：取游客最新数量覆盖或累加（主流采用「客户端为准」更贴合用户体验）

• 不同SKU：全部合并保留，不丢失任何商品

• 合并完成后，清空游客临时购物车

架构避坑：绝对禁止直接覆盖用户原有购物车数据，会引发大规模用户投诉。

五、生产级表结构设计（登录用户购物车）

游客购物车不落地数据库，仅登录用户购物车做持久化存储，下表为大厂通用生产表结构，精简无冗余、索引合理、适配亿级用户。

-- 用户购物车表 cart_user
id             BIGINT    雪花主键ID
user_id        BIGINT    用户ID
sku_id         BIGINT    商品SKU ID
spu_id         BIGINT    商品SPU ID
sku_name       VARCHAR   SKU规格名称
spec_value     VARCHAR   规格组合值
goods_num      INT       购买数量
is_checked     TINYINT   是否勾选（0-否 1-是）
add_time       DATETIME  加入购物车时间
update_time    DATETIME  更新时间
is_valid       TINYINT   是否有效（0-失效 1-有效）

-- 核心索引
PRIMARY KEY (id)
INDEX idx_user_id (user_id)               -- 极速查询用户购物车列表
UNIQUE KEY idx_user_sku (user_id,sku_id)  -- 唯一约束，防止同一用户重复加购相同SKU
INDEX idx_add_time (add_time)             -- 用于冷热数据分层、过期清理

设计亮点：唯一索引杜绝重复加购脏数据、时间索引支撑冷热分层、状态字段支持失效商品过滤。

六、亿级用户购物车冷热数据分离架构（核心性能方案）

6.1 痛点分析

普通架构所有购物车数据全部常驻数据库和缓存，用户常年不清理的老旧商品、失效商品、下架商品堆积，数据量爆炸、查询变慢、缓存臃肿、大促加载卡顿。

6.2 冷热分层标准（大厂通用）

6.2.1 热数据（活跃购物车）

近30天新增/编辑/勾选过的购物车商品，常驻Redis缓存 + MySQL主表，前台优先加载、毫秒级响应。

6.2.2 冷数据（沉睡购物车）

超过30天无任何操作、未勾选、长期静置的商品，判定为冷数据。

处理策略：定时任务归档至购物车历史表、清空对应缓存、前台默认不展示，用户点击「查看历史购物车」才加载。

6.3 核心价值

极大缩减热数据体量，缓存命中率大幅提升，大促高峰期购物车列表加载速度提升5-10倍，彻底解决海量数据碾压问题。

七、大促高并发加购架构方案

7.1 高并发核心瓶颈

大促瞬间海量加购请求，直接打穿数据库、重复请求刷屏、接口抖动超时、数据重复写入。

7.2 四层防护架构（生产落地）

7.2.1 前端防抖

加购按钮置灰、禁止重复点击、短时间请求拦截，从入口拦截无效流量。

7.2.2 接口幂等

基于用户ID+SKU维度做幂等校验，同一用户同一SKU短时间重复请求直接拦截，杜绝重复数据。

7.2.3 Redis先行写入

所有加购请求先写缓存、异步落库，主链路无DB压力，支撑十万级QPS。

7.2.4 流量限流熔断

网关层针对购物车接口做限流、Sentinel熔断兜底，防止服务雪崩，保护核心交易链路。

八、购物车实时数据联动机制（价格+库存+状态）

购物车最大的用户体验问题：商品变价、下架、库存不足，购物车不刷新，用户结算报错。

8.1 商品状态联动

商品下架、删除、售罄后，用户购物车对应商品自动标记为失效商品，置灰不可勾选，结算自动过滤。

8.2 实时价格联动

购物车列表不展示本地旧价格，每次进入购物车实时调用价格引擎，获取最新售价、活动价、优惠价，保证价格绝对一致。

8.3 库存前置校验

进入购物车、结算前置校验库存，库存不足直接提示，避免用户选品完成后结算失败，优化体验、减少无效交易请求。

九、生产高频踩坑复盘（真实线上事故）

9.1 坑点1：登录购物车覆盖游客数据，引发大规模客诉

现象：用户未登录加购多个商品，登录后部分商品消失。

根因：架构采用粗暴覆盖策略，未做合并逻辑。

根治方案：标准化合并策略，同SKU合并数量、异SKU全部保留。

9.2 坑点2：无唯一索引，用户购物车出现大量重复商品

现象：网络抖动重复提交，同一SKU在购物车重复出现多条。

根因：数据库无唯一约束、接口无幂等控制。

根治方案：用户ID+SKU唯一索引 + 接口幂等双重兜底。

9.3 坑点3：购物车堆积大量下架失效商品

现象：用户购物车几十条失效商品，页面杂乱、加载缓慢、结算卡顿。

根因：无失效清理、无冷热分层机制。

根治方案：定时任务自动归档冷数据、失效商品自动标记、前台智能过滤。

9.4 坑点4：缓存与数据库数据不一致

现象：数据库已修改数量，前台展示旧数据。

根因：更新DB未更新缓存、缓存残留旧数据。

根治方案：更新数据库后主动淘汰缓存，异步兜底刷新，保证最终一致性。

十、大厂面试高频考点 & 架构师高分话术

1. 购物车未登录和登录状态如何设计？为什么游客数据不落地数据库？

2. 用户登录购物车合并策略是什么？如何避免数据丢失和覆盖？

3. 亿级用户下购物车如何做性能优化？冷热数据分层思路？

4. 大促高并发加购如何防雪崩、防重复、保性能？

5. 购物车价格和库存如何保证和详情页、结算页一致？

高分架构思路：先讲双模型架构 → 再讲合并策略 → 再讲冷热分层性能优化 → 再讲高并发防护 → 最后讲数据一致性兜底，体现完整系统化架构能力。

十一、本篇总结 & 下篇预告

11.1 本篇总结

本文完整落地了亿级电商购物车架构，彻底告别CRUD浅层开发思维，掌握双模型设计、购物车合并、冷热分层、高并发加购、数据联动、一致性兜底等架构级核心能力。

核心架构思维：购物车是临时预购容器，轻薄、高速、高可用是第一优先级，所有重计算、重事务全部外溢解耦。

11.2 下篇预告

下一篇我们将进入电商核心核心：价格引擎与营销体系架构，深度拆解商品原价、活动价、优惠券、满减、秒杀、叠加规则、价格校验、防薅羊毛机制，吃透电商最复杂、面试最爱问的价格体系架构。