如何设计一个购物车系统？

🪴 Obsidian Publish

需求分析

初级需求分析：

商品加入购物车
查看购物车列表
发起结算下单

用户体验需求分析：

用户未登录，浏览器中加购商品，登录后是否保留？
用户未登录，浏览器中加购商品，关闭再打开浏览器后是否保留？
用户登录，关闭再打开浏览器，是否保留？
…

主要属性

购物车系统，只有一个实体 —— 购物车，购物车里为一个个待下单的选项。

每一个选项包含：商品 SKUID、加入购物车时间、数目、勾选状态。

需求实现设计

暂存购物车

如果需要实现“暂存购物车”，即用户没有登录时的加购的商品。

首先分析存储位置，服务端肯定不合适，无法知道合适删除“暂存购物车”，导致数据激增。那么只能是客户端存储，客户端合适的方案有：Cookie 和 LocalStorage 存储。

Cookie 存储的优点：每次与服务端交互都会携带，和购物车交互逻辑可以在服务端完成（加购、删除商品）并且实现很简单。

Cookie 存储的缺点：Cookie 只能存储 4KB 数据，对于商品种类数量较多的平台，有可能导致超出存储上限。

LocalStorage 存储的优点：存储容量比 Cookie 的 4KB 上限大得多，而且不用每次请求都要带着，可节省带宽。

LocalStorage 存储的缺点：实现复杂，客户端和服务端都要实现业务逻辑。

存储的时候，直接一个 JSON 按照“主要属性”中的存储就可以。

用户购物车

CREATE TABLE shopping_cart (
    id BIGINT AUTO_INCREMENT PRIMARY KEY NOT NULL COMMENT '自增主键',
    user_id BIGINT NOT NULL COMMENT '用户 ID',
    sku_id BIGINT NOT NULL COMMENT '商品 ID',
    count INT NOT NULL COMMENT '商品数量',
    timestamp DATE NOT NULL COMMENT '加购时间',
    selected TINYINT(1) COMMENT '购选状态',
    INDEX idx_user_id (user_id)
);

user_id 上增加索引，是因为查询购物车状态都是以 user_id 为基础的。

也可以使用 Redis 来保存购物车信息，用户 ID=Key，Redis 的 HASH=Value，保存购物车中的商品。

至于是否需要 Redis，需要根据存储/开发/维护成本、性能、数据一致性等角度去思考。