基于本文回答

播面 播面

刷题像听歌，多听自然懂
0
评论
请从左侧选择一个分类

未登录和登录状态下的购物车数据如何存储和合并？

知识点图片

这是一个非常经典的电商系统架构问题。设计良好的购物车系统需要兼顾用户体验（无缝切换）和系统性能（读写速度）。

以下是关于未登录和登录状态下购物车数据存储与合并的详细技术方案：

一、 数据存储方案

1. 未登录状态（游客购物车）

核心目标：在用户没有身份标识的情况下，临时保存其意向商品。

  • 方案 A：纯客户端存储 (Cookie / LocalStorage)
    • 实现：将购物车数据序列化为 JSON 字符串存储在浏览器的 LocalStorage 或 Cookie 中。
    • 优点：不占用服务器资源，实现简单。
    • 缺点：
      • 更换设备/浏览器后数据丢失。
      • Cookie 有大小限制（4KB），LocalStorage 虽然大（5MB+）但无法被服务端直接读取用于分析。
      • 安全性较低，容易被篡改。
  • 方案 B：服务端存储 + 临时 Token (推荐 - 工业级做法)
    • 实现：
      1. 用户首次访问时，服务端生成一个唯一的 UUID (例如 user_temp_id)。
      2. 将该 UUID 写入用户的浏览器 Cookie (设置较长的过期时间)。
      3. 购物车数据存储在服务端的 Redis 中，Key 为 cart:temp:{uuid}。
    • 优点：
      • 数据结构灵活，支持大数据量。
      • 便于运营分析（即使用户未登录，也能分析加购行为）。
      • 性能高（Redis 读写快）。
    • 缺点：占用一定的 Redis 内存资源（通常设置 7-30 天的过期时间）。

2. 登录状态（用户购物车）

核心目标：数据持久化，跨设备同步。

  • 存储架构：Redis (主) + Database (辅)
    • Redis：用于高频读写。用户频繁修改数量、勾选商品，直接操作 Redis。
      • Key 命名：cart:user:{userId}
      • 数据结构：推荐使用 Hash 结构。Key 是用户ID，Field 是商品 SKU ID，Value 是商品详情（数量、加购时间、勾选状态等 JSON）。
    • Database (MySQL/Mongo)：用于数据持久化兜底。
      • 当 Redis 数据发生变化时，通过异步消息队列 (MQ) 或定时任务同步到数据库，防止 Redis 宕机导致数据丢失。
      • 或者在用户下单成功后，才将购物车数据归档。

二、 购物车合并策略

核心场景：用户在“未登录”状态下加购了商品 A 和 B，然后点击“登录”。登录成功后，需要将游客购物车的 A 和 B 合并到该账号原有的购物车中。

1. 合并时机

通常在登录接口验证通过后，返回登录成功响应之前，或者通过异步事件触发合并逻辑。

2. 合并逻辑流程

假设：

  • 游客购物车 (Temp Cart)：包含商品 [A (数量1), B (数量2)]
  • 用户原购物车 (User Cart)：包含商品 [B (数量1), C (数量1)]

合并步骤如下：

  1. 获取数据：

    • 根据 Cookie 中的 user_temp_id 从 Redis 读取游客购物车数据。
    • 根据登录后的 user_id 从 Redis/DB 读取用户原购物车数据。

  2. 判空处理：

    • 如果游客购物车为空：无需合并，直接返回用户原购物车。
    • 如果用户原购物车为空：直接将游客购物车的数据 复制/移动 到用户购物车 Key 下。

  3. 冲突处理 (核心算法)：
    当两边都有数据时，需要遍历游客购物车中的商品：

    • 场景 1：商品相同 (SKU ID 一致)
      • 累加数量：用户车.B.数量 = 用户车.B.数量 + 游客车.B.数量 (例如：1 + 2 = 3)。
      • 注意：累加后需校验库存上限或限购策略。
    • 场景 2：商品不同
      • 新增条目：将商品 A 直接追加到用户购物车中。

  4. 数据回写：

    • 将合并后的新数据写入 Redis 的 cart:user:{userId}。
    • 触发异步任务同步到数据库。

  5. 清理临时数据：

    • 删除 Redis 中的 cart:temp:{uuid}。
    • (可选) 清除浏览器中对应的临时 UUID Cookie，或者保留它以便下次退出登录后继续作为游客标识。

3. 代码逻辑伪代码 (Python/Redis 风格)

python 
def login(username, password, temp_uuid):
    user_id = verify_user(username, password)
    if not user_id:
        return "Login Failed"

    # 1. 获取两个购物车的数据
    guest_cart_key = f"cart:temp:{temp_uuid}"
    user_cart_key = f"cart:user:{user_id}"
    
    guest_cart = redis.hgetall(guest_cart_key) # {sku_1: count, sku_2: count}
    
    if guest_cart:
        # 2. 遍历游客购物车进行合并
        for sku_id, count in guest_cart.items():
            # hincrby 自动处理了两种情况：
            # 如果 sku_id 存在，则累加数量
            # 如果 sku_id 不存在，则创建并设置数量
            redis.hincrby(user_cart_key, sku_id, count)
        
        # 3. 清除游客购物车
        redis.delete(guest_cart_key)
        
        # 4. 异步同步到数据库 (伪代码)
        send_message_to_mq("sync_cart_to_db", user_id)

    return "Login Success"

三、 常见问题与细节优化

  1. 离线购物车的有效期 (TTL)

    • 游客购物车的 Redis Key 应该设置过期时间（如 7 天或 30 天）。如果用户长期不登录，这些临时数据应该被自动清理以释放内存。

  2. 勾选状态的合并

    • 通常策略是：合并后默认全部选中，或者保留游客车的选中状态。这取决于产品经理的要求，一般倾向于让用户更容易去结算，所以合并进来的新商品通常设为选中。

  3. 库存超限问题

    • 合并时如果 数量 A + 数量 B > 库存上限，需要将数量重置为最大可购买库存，并在前端给用户提示（如：“部分商品数量已调整至最大库存”）。

  4. 接口响应速度

    • 如果购物车数据量很大，合并过程可能会拖慢登录接口。
    • 优化：登录接口只做简单的身份验证，验证通过后发放 Token。前端拿到 Token 后，立即在后台静默调用一个 POST /cart/merge 接口，或者由后端通过消息队列异步处理合并，前端在进入购物车页面时再拉取最新数据。

四、 总结

特性 未登录 (游客) 已登录 (用户)
标识 浏览器 Cookie 中的 UUID 用户 UserID
存储位置 Redis (Key带TTL) 或 LocalStorage Redis (持久化) + MySQL
数据生命周期 临时，随 Cookie 清理或 Redis 过期丢失 永久，跨设备同步
合并策略 并集操作：相同商品数量累加，不同商品追加

最佳实践流程：
用户打开 App (生成 UUID) -> 加购 (存入 Redis temp) -> 登录 -> 后端检测到 UUID -> 读取 temp 数据 -> 合并入 user 数据 -> 删除 temp 数据 -> 返回最新购物车。

00:00
00:00