先给结论

有需要被"记住"而非仅仅被"看到"的信息。 用户在淘宝上的每一次点击可以被遗忘（缓存过期），但他的每一笔交易必须被铭记（DB永存）。这就是工业级系统设计中"性能"与"正确"之间的永恒权衡。

我们必须先建立一个认知：缓存是“便签纸”，关系型数据库才是“法律账本”。

便签纸（缓存）写得快、看得快，但可能写错、可能丢失、可能被风吹走；而法律账本（DB）写得慢，但它是唯一具备法律效力、绝对准确、永久保存的依据。

下面我以 “用户在淘宝下单买一件衣服” 的全流程为例，详细拆解哪些数据必须落DB，哪些放缓存，以及为什么。

1. 核心原则：什么决定了数据存哪里？

2. 购物全流程数据归属详解

场景一：浏览商品详情页

关键点：库存的"双写"逻辑
用户点击"立即购买"时，先在Redis中执行DECR扣减库存（毫秒级响应，抗住秒杀流量）。但这只是"预扣"，真正的库存变更必须在订单创建事务中写入PolarDB。如果订单取消或支付超时，Redis和DB都要回滚。Redis是"挡箭牌"，DB是"真账本"。

场景二：提交订单

为什么订单必须落DB？

• 事务性：扣库存、创建订单、扣优惠券、记积分，这4个操作要么全成功要么全失败，只有DB支持ACID事务。
• 可追溯：3个月后用户投诉"我没收到货"，客服需要从DB查出完整订单链路。缓存早就过期了。
• 合规性：电商法要求交易记录保存至少3年，缓存无法承担此法律责任。

场景三：支付与履约

场景四：用户相关数据

3. "强一致"到底意味着什么？

以支付为例，对比两种一致性模型：

一句话总结
"强一致" = 在任何时刻、任何节点、任何故障场景下，读到的数据都等于最后一次成功写入的值。 这是用性能和复杂度换来的"绝对正确"，只用在"错了就出大事"的地方。

4. 架构全景图：一次购物的数据流转

用户点击"购买" │ ▼ ┌──────────────┐ 预扣库存 ┌─────────────┐ │ 前端/App │ ─────────────→ │ Tair(Redis) │ ← 毫秒级响应，抗并发 └──────────────┘ └─────────────┘ │ │ │ 创建订单(同步) │ 异步同步 ▼ ▼ ┌──────────────────────────────────────────────┐ │ PolarDB / OceanBase │ │ ┌─────────┐ ┌─────────┐ ┌────────────────┐ │ │ │订单表 │ │库存表 │ │优惠/支付流水表 │ │ │ │(强一致) │ │(强一致) │ │(强一致) │ │ │ └─────────┘ └─────────┘ └────────────────┘ │ │ ↑ ACID事务保证原子性 │ └──────────────────────────────────────────────┘ │ │ 订单创建成功 → 发消息 ▼ ┌──────────────┐ │ 消息队列 │ → 通知缓存更新订单状态 │ (RocketMQ) │ → 触发积分/通知等异步任务 └──────────────┘

终极总结