先给结论有需要被记住而非仅仅被看到的信息。 用户在淘宝上的每一次点击可以被遗忘缓存过期但他的每一笔交易必须被铭记DB永存。这就是工业级系统设计中性能与正确之间的永恒权衡。我们必须先建立一个认知缓存是“便签纸”关系型数据库才是“法律账本”。便签纸缓存写得快、看得快但可能写错、可能丢失、可能被风吹走而法律账本DB写得慢但它是唯一具备法律效力、绝对准确、永久保存的依据。下面我以 “用户在淘宝下单买一件衣服” 的全流程为例详细拆解哪些数据必须落DB哪些放缓存以及为什么。1. 核心原则什么决定了数据存哪里判定维度放关系型数据库 (PolarDB/OceanBase)放缓存 (Tair/Redis)一致性要求强一致绝对不能错最终一致允许短暂不准数据生命周期永久保存临时/有TTL业务后果错了资损/法律风险/客诉错了体验下降/可重试操作类型复杂事务、关联查询、聚合统计简单KV读写、高频计数数据价值核心资产加速副本2. 购物全流程数据归属详解场景一浏览商品详情页数据项存储位置原因商品标题、描述、SKU属性缓存 (主) DB (备)读多写少缓存命中率高修改时异步刷新缓存商品主图/视频CDN OSS大文件不适合进KV缓存实时价格缓存 DB价格变更时通过消息队列秒级刷新缓存DB是定价权威来源实时库存缓存 (扣减) DB (校准)高并发下用Redis原子扣减防超卖订单创建成功后异步落DB持久化评论列表缓存 Lindorm评论内容存Lindorm(宽表)热门评论摘要进Redis猜你喜欢推荐缓存推荐引擎预计算结果纯读场景关键点库存的双写逻辑用户点击立即购买时先在Redis中执行DECR扣减库存毫秒级响应抗住秒杀流量。但这只是预扣真正的库存变更必须在订单创建事务中写入PolarDB。如果订单取消或支付超时Redis和DB都要回滚。Redis是挡箭牌DB是真账本。场景二提交订单数据项存储位置原因订单主表PolarDB/OceanBase核心交易数据涉及资金、履约、售后必须强一致永久存储订单明细(SKU/数量/单价)PolarDB/OceanBase与主表在同一事务中写入保证原子性优惠快照(用了什么券/满减)PolarDB/OceanBase退款/审计时必须精确还原当时优惠规则收货地址快照PolarDB/OceanBase用户后续修改地址不影响历史订单订单号生成Tair(序列号) DBRedis自增生成全局唯一IDDB记录映射关系购物车状态缓存 (主)购物车是临时意图非正式交易DB仅做异步持久化防丢失为什么订单必须落DB事务性扣库存、创建订单、扣优惠券、记积分这4个操作要么全成功要么全失败只有DB支持ACID事务。可追溯3个月后用户投诉我没收到货客服需要从DB查出完整订单链路。缓存早就过期了。合规性电商法要求交易记录保存至少3年缓存无法承担此法律责任。场景三支付与履约数据项存储位置原因支付流水OceanBase资金数据金融级强一致RPO0支付状态回调DB 缓存DB持久化缓存更新订单状态供前端快速轮询物流单号/轨迹DB 缓存DB存权威记录缓存存最新轨迹供高频查询发票信息PolarDB税务合规不可变风控决策结果缓存实时拦截用事后分析从日志/数仓取场景四用户相关数据数据项存储位置原因用户名/手机号/实名信息PolarDB核心身份数据加密存储强一致Session/Token缓存登录态是临时的过期即失效用户标签(偏好/等级)缓存 DB画像系统预计算写缓存DB存原始行为数据浏览/搜索历史缓存(近期) Lindorm(长期)近期行为用于实时推荐长期行为用于离线分析收藏夹缓存 DB高频读走缓存DB保证换设备后数据不丢3. 强一致到底意味着什么以支付为例对比两种一致性模型维度强一致 (OceanBase/PolarDB)最终一致 (Redis缓存)写入后读取立即读到最新值可能读到旧值延迟ms~s级故障恢复RPO0数据零丢失可能丢失未持久化的写入跨行/跨表支持分布式事务不支持适用场景转账、下单、库存确权展示、计数、会话、预扣代价延迟较高(ms级)吞吐受限延迟极低(μs级)吞吐极高一句话总结强一致 在任何时刻、任何节点、任何故障场景下读到的数据都等于最后一次成功写入的值。 这是用性能和复杂度换来的绝对正确只用在错了就出大事的地方。4. 架构全景图一次购物的数据流转用户点击购买 │ ▼ ┌──────────────┐ 预扣库存 ┌─────────────┐ │ 前端/App │ ─────────────→ │ Tair(Redis) │ ← 毫秒级响应抗并发 └──────────────┘ └─────────────┘ │ │ │ 创建订单(同步) │ 异步同步 ▼ ▼ ┌──────────────────────────────────────────────┐ │ PolarDB / OceanBase │ │ ┌─────────┐ ┌─────────┐ ┌────────────────┐ │ │ │订单表 │ │库存表 │ │优惠/支付流水表 │ │ │ │(强一致) │ │(强一致) │ │(强一致) │ │ │ └─────────┘ └─────────┘ └────────────────┘ │ │ ↑ ACID事务保证原子性 │ └──────────────────────────────────────────────┘ │ │ 订单创建成功 → 发消息 ▼ ┌──────────────┐ │ 消息队列 │ → 通知缓存更新订单状态 │ (RocketMQ) │ → 触发积分/通知等异步任务 └──────────────┘终极总结问题答案哪些必须落DB一切涉及钱、权、责、法的数据订单、支付、库存确权、用户身份、合同、发票哪些放缓存一切为了快、省、扛的数据商品展示、Session、预扣库存、推荐结果、热点配置两者关系DB是真相之源缓存是高性能投影。缓存可以脏、可以丢、可以过期但DB永远是对的为什么不全放DBDB扛不住百万QPS延迟也满足不了用户体验为什么不全放缓存缓存没有事务、不能持久、无法追责用来管钱等于裸奔