乐优商城全链路架构设计复盘：从商品模型到库存扣减的避坑指南

乐优商城这个项目我前前后后带人维护了近两年。它是典型的全链路电商系统商品、库存、搜索、购物车、订单、支付、促销、后台管理一样不缺。当时团队定这个项目的目标很明确不是去比架构多华丽而是要在可控成本内让用户从浏览商品到下单支付、售后完成的全流程都跑得稳。做完之后回头看它更像一个“浓缩版电商教材”——每个模块单看都不算难但把它们串在一起并发、一致性、可用性的问题就全冒出来了。这篇文章我不打算写成功能清单而是想以项目复盘的方式把乐优商城的整体设计、核心模块、关键实现以及我们踩过的坑和排查思路拆开讲。如果你正准备做电商项目或者想理解一个成熟商城系统内部是怎么运转的这篇内容大概率能给你一些直接能用的经验。1. 项目整体定位与技术选型思路1.1 商城系统到底要解决什么问题电商系统看起来很直观用户看到的是商品页、购物车、下单按钮但支撑这些界面背后的业务比想象中复杂得多。先说角色。乐优商城服务的用户大概分三类普通消费者、运营人员、系统管理员。消费者走购物链路运营管理商品上下架和营销活动管理员管用户、订单、数据统计。不同角色对系统能力的要求不一样做设计时不能被“购物流程”这四个字带偏得先想清楚系统边界。再看购物链路。用户从搜索或分类进入商品详情页把商品加入购物车确认订单后生成支付成功后进入履约流程。这个链路上至少涉及几个关键动作商品信息读取、库存判断、价格计算、订单生成、支付回调、扣减库存。任何一个环节出问题用户的体感都是“下单失败”或者“支付了但订单没生成”。所以我一直认为商城项目的核心不在“功能多”而在“流程闭环”。乐优商城在设计初期我们就把主流程定义得非常明确浏览商品 - 加购 - 下单 - 支付 - 发货 - 收货 - 售后。所有技术方案都是围绕这条主流程来做的。1.2 技术选型背后的取舍逻辑乐优商城没有采用单体应用而是拆成了一组核心服务。不是因为它规模大得必须微服务而是因为业务边界实在太清晰了商品服务、搜索服务、购物车服务、订单服务、库存服务、用户服务、支付服务、后台管理服务天然可以独立开发、独立发布、独立扩容。技术栈基本是主流电商项目的标准组合Spring Boot Spring Cloud 做服务框架和微服务治理MySQL 存业务主数据商品、用户、订单分开库Redis 承担缓存、分布式 Session、库存扣减Elasticsearch 做商品搜索RabbitMQ 解耦订单、库存、支付之间的异步通知Docker 容器编排工具做部署每个组件选型都有对应的理由。比如搜索用 Elasticsearch是因为数据库里的 LIKE 查询在多条件组合下几乎无法保证性能而商品筛选本质上是倒排索引 聚合统计的问题。订单和库存之间用 MQ是因为支付回调后需要通知多个服务如果同步调用任何一个服务的抖动都会拖垮支付流程。Redis 做库存扣减是另一个关键决策。数据库行锁在低并发下没问题但秒杀或促销高峰时性能会断崖下跌。用 Redis 的原子操作来扣预库存数据库只做最终一致性校验这是目前性价比最高的方案之一。这部分后面我会展开讲。选型最容易被忽视的一点是运维成本。团队总共没几个人所以能用托管组件解决的问题就不要自建。不过为了控制成本存储和中间件最终是自己部署的这也让我们在排查问题上积累了挺多经验。2. 核心业务模块设计与拆解2.1 商品管理与SPU/SKU模型商品数据模型是商城的地基地基没打好后面搜索、购物车、订单都会连累。乐优商城采用了业界常用的 SPU / SKU 模型。SPU 是标准化产品单元比如“某品牌运动鞋”就是 SPUSKU 是具体可下单的库存单位比如“某品牌运动鞋-黑色-42码”。这个区分很重要因为商品详情页展示的信息属于 SPU 级别而库存、价格、下单则属于 SKU 级别。规格参数是商品模型里最容易做错的部分。我们一开始用字段拼接的方式搞规格比如颜色、尺码全放在一个字符串里后来筛选功能完全没法做。正确做法是把规格抽象成属性键值对一个 SPU 挂多个规格属性属性组合决定 SKU。为了适配不同类型的商品属性还要区分“全局属性”和“商品自定义属性”不然手机可以按屏幕尺寸筛选衣服没法按这个筛。商品上下架和库存的关系也要理清。下架不是简单地把商品隐藏而是要考虑购物车中已有商品的处理、搜索索引的更新、促销活动的下线。我们曾经出现过运营下架商品后用户购物车里还能下单的情况原因就是购物车服务只校验了商品状态没有回源查商品服务的最新状态。2.2 商品搜索与筛选聚合搜索是商城流量的主要入口用户体验很大程度取决于搜索结果准不准、筛选够不够细。乐优商城的搜索链路是MySQL 商品数据变更后通过 MQ 通知搜索服务增量更新索引用户请求进来后先经过分词和查询改写再根据分类、品牌、价格区间、规格属性等条件做过滤和聚合。真实场景下用户最常做的事不是输入精确关键词而是“随便看看”所以筛选聚合甚至比关键词匹配还重要。索引设计有几个细节值得分享。第一参与排序和筛选的字段要用非分词类型存储比如品牌 ID、分类 ID 必须精确匹配第二价格区间最好用数字类型而不是字符串否则排序会得到奇怪的结果第三规格属性的聚合要在查询时动态计算而不是提前把全量聚合结果缓存因为商品价格和库存经常变化。搜索还有一个容易踩的坑同义词和错误容忍。用户搜“苹果手机”可能想找 iPhone搜“笔记本”可能既想找笔记本电脑也想找纸质笔记本。我们当时在查询改写上做了一些同义词映射和纠错处理搜索点击率明显提升。这些事看起来不性感但对商城转化率实打实有影响。2.3 购物车与订单状态机购物车看起来是个简单的存储问题真正做起来才发现有隐含需求未登录用户也要能加购登录后要合并购物车里的商品可能已经下架或改价结算时还要重新校验。乐优商城的购物车服务用 Redis 存储key 按照用户维度设计。未登录时用临时标识登录后把临时购物车合并到用户购物车。合并逻辑并不简单同 SKU 数量要累加超出库存上限的要截断失效商品要剔除。最开始我们直接覆盖合并结果用户反馈“购物车东西少了”后来改成逐项比对才解决。订单模块的核心是状态机设计。订单从创建到结束状态不能随便跳转必须符合业务规则。乐优商城定义了这么一套状态待支付、已支付待发货、已发货、已完成、已取消、已关闭。状态变更统一走订单服务不允许各个业务方直接改订单表。否则你根本不知道哪个服务把订单状态改坏了。订单号生成也参考了常见的雪花算法方案但它不是单纯用时间戳拼接。我们把订单号设计成“时间 机器号 序列号”的组合既能保证全局趋势递增又能在分布式环境下避免重复。数据库层面订单表按用户维度做了分片避免单表数据量过大影响查询性能。2.4 支付对接与回调处理支付是电商系统里容错要求最高的环节因为涉及真金白银一个重复回调或回调丢失都可能造成资损或用户体验问题。乐优商城的做法是下单时创建支付单支付成功后支付渠道回调通知支付服务支付服务更新支付单状态再通过 MQ 通知订单服务更新订单状态。做这个流程最关键的是幂等支付回调可能来两次网络超时重试也可能导致重复通知业务上必须保证同一笔支付单的处理结果一致。我们在支付回调处理上加了一个状态机校验只有初始状态能变更为成功状态重复回调直接返回成功不再重复触发后续流程。与此同时用户主动查询支付结果、对账定时任务、人工介入三种方式共同保证最终一致避免完全依赖回调导致单点失败。支付这块还想提醒一句永远不要在前端判断支付成功前端跳转结果页很容易伪造。所有订单状态的变更必须以服务端回调为准。3. 关键环节实操与避坑指南3.1 库存扣减从数据库锁到Redis脚本库存是电商并发问题的高发区。丢单可以接受超卖绝对不行。我们最早实现的版本是下单时执行数据库更新UPDATE sku SET stock stock - 1 WHERE id ? AND stock 0。这个写法在低并发下是安全的因为行锁保证只有一个事务能更新成功。但到了秒杀场景热点行锁竞争会让数据库的活跃连接数瞬间拉满CPU打高整个订单服务跟着雪崩。后来我们把库存拆分成了两层Redis 预扣库存 数据库可靠扣减。用户下单时先操作 Redis 库存扣减成功才允许创建订单。为了保证扣减的原子性我们直接用 Lua 脚本在 Redis 服务端执行local stock tonumber(redis.call(GET, KEYS[1])) if not stock then return -1 end if stock tonumber(ARGV[1]) then redis.call(DECRBY, KEYS[1], ARGV[1]) redis.call(SADD, KEYS[2], ARGV[2]) return 1 end return 0这个脚本做了两件事判断库存是否充足然后扣减库存并记录扣减痕迹。整个操作在 Redis 内原子执行没有并发窗口。数据库层面则不直接减库存而是根据 Redis 扣减成功的记录做异步落库和校验。这样既保证了秒杀场景的响应速度又让最终数据有可靠存储。这里有个必须注意的坑Redis 库存和数据库库存要保持最终一致。如果订单支付超时被取消要释放 Redis 库存如果支付成功要确保数据库库存也扣减。我们在取消订单和支付回调里都加了库存补偿逻辑宁可多执行一次也不能漏执行。3.2 订单超时取消与消息可靠投递订单创建后用户不支付不能一直占库存所以必须有超时取消机制。乐优商城最初用的是定时任务扫表把所有超时未支付订单批量取消。这个方案最大的问题是时间不准而且数据库压力大。后来我们改成延时消息的方案订单创建后发送一条延时消息时间到后消费者检查订单状态如果是待支付就取消订单并释放库存。这个方案比扫表高效但引入了新的问题——消息丢失怎么办。我们的兜底是定时任务扫描订单只处理最近几分钟内应该超时但还没被取消的订单。因为操作量级小对数据库压力可以忽略同时又避免消息丢失导致订单永远不取消。这套“延时消息为主、定时扫描兜底”的组合上线后基本没有出现过超时未关单的情况。MQ 消息可靠性的另一个重点是消费端幂等。同一笔订单可能同时收到支付成功通知和库存释放通知如果消费逻辑没有幂等判断就可能出现重复退款或者重复加库存。我们在所有 MQ 消费入口都加了业务主键去重宁可消费重复也不能处理重复。3.3 前端性能与首屏加载商城的前端体验直接影响转化率特别是商品列表和详情页。首屏加载慢通常不是前端代码的问题而是接口链路太长。乐优商城商品详情页要展示基础信息、图片、规格、库存、价格、评价如果每个信息都由前端并发请求一方面接口数量多另一方面每个接口的耗时都会拖慢页面渲染。我们的做法是做页面聚合接口。商品详情服务把基础信息、价格、库存等数据一次性聚合好再返回给前端。这个接口内部并行调用多个基础服务用 CompletableFuture 组合结果。接口整体耗时从原来的 800 多毫秒降到了 150 毫秒左右体感提升非常明显。静态资源的 CDN 缓存也值得重视。图片和商品描述这类不怎么变化的内容坚决要走 CDN并且根据业务场景设置合理的缓存过期时间。上活动时最怕的就是图片加载慢把静态资源缓存策略配好能省下不少不必要的带宽成本。3.4 日志、链路追踪与灰度发布服务拆分的代价是排查问题变难了。以前单体应用一条日志从头打到尾微服务下一个请求可能跨五个服务出了问题得逐台机器翻日志。乐优商城在项目中期接入了链路追踪把请求 ID 贯穿整条调用链。这个改造的收益在线上故障排查时体现得特别明显。以前查一个问题要开三四个终端来回看日志现在是输入请求 ID一条链路上下游的耗时、参数、异常信息全都能看到。上线发布也做了灰度策略。先让一小部分流量走新版本观察错误率和关键接口耗时没问题再全量。这套机制帮我们避免过好几次“上线即故障”的情况代价只是多写了一点发布脚本和开关配置非常划算。4. 常见问题与排查实录4.1 高频问题速查表我把乐优商城开发和维护中遇到的典型问题整理成了一张表按现象定位根因再给解决方案。做项目时遇到类似情况可以从这里先对照一遍。现象潜在根因解决手段下单时偶发“库存不足”Redis 库存与数据库库存不一致核对取消订单和支付回调的补偿逻辑支付成功但订单状态未更新支付回调消息丢失消费端日志确认 定时对账任务补单页面筛选结果不稳定搜索索引未及时更新检查 MQ 增量更新链路必要时手动全量重建后台改价后前端没变化商品缓存未失效缓存删除加 MQ 通知统一走缓存更新入口大促时接口延迟上升数据库连接池被打满前置缓存和限流数据库连接池设置监控告警购物车合并后商品消失合并逻辑覆盖了无效商品逐项合并无效商品单独标记并提示用户订单重复创建前端重复提交创建订单接口做防重令牌服务端幂等校验表格里能直接解决的当然好但现实里问题往往不会这么标准需要看日志、比对数据才能定位。4.2 印象最深的三次线上问题排查第一次是凌晨大促时订单重复创建。用户连续点击下单按钮没有防重控制。前端按钮置灰能解决一部分问题但真要防住得在服务端做幂等。我们在创建订单接口增加了一个 token 机制用户进入结算页时先从服务端获取一个唯一令牌下单时必须携带令牌同一令牌只能成功创建一次订单。改完之后重复下单问题基本消失。第二次是商品价格被篡改。有个用户通过修改请求参数用极低的价格下单成功。复盘后发现订单服务在做价格计算时前端传过来的单价直接参与了金额计算。正确逻辑是所有金额都以服务端商品数据为准前端参数只能传 SKU ID 和数量。后来我们把计价逻辑收敛到订单服务内部并且加了金额校验规则才算把这个问题彻底堵住。第三次是数据库连接被打满。现象是下单接口大面积超时数据库活跃连接数暴涨。排查后发现是因为秒杀活动瞬间流量过大库存查询语句走了 Redis但订单创建时仍有大量请求直接访问数据库。我们随后在库存服务前面加了限流和排队机制同时扩大了 Redis 缓存覆盖面数据库连接数才开始回落。这次教训让我们意识到压测不能只看平均流量要看瞬间峰值。5. 部署上线与后续演进思路5.1 环境部署与容量预估乐优商城的部署不算复杂但环境分离一定要做清楚。开发、测试、预发布、生产四个环境数据严格隔离。最容易出问题的是预发布环境连了生产数据库导致预发测试把线上数据搞脏。服务部署用的容器编排每个服务独立部署。数据库和 Redis 单独跑在专用机器上减少相互影响。上线前要做容量预估主要看日均订单量和峰值 QPS。我们的粗略算法是峰值 TPS 日均订单量 / 峰值小时占比 / 3600再乘以一个 3 到 5 的冗余系数。这套估算方法不算精确但足够做资源申请了。压测是一定要做的。我们用压测工具模拟下单流程重点看订单服务、库存服务和数据库的拐点在哪。压测不是量越大越好而是找到系统在多少 QPS 时开始不稳定从而设置合理的限流阈值。乐优商城的限流阈值就设置在压测出的拐点之前给系统留了缓冲空间。5.2 如果再让我做一次会怎么调整做完整个项目我的体会是先把主流程做得无限稳定再谈功能扩展。如果重新做一次我会把更多精力放在基础数据模型和监控告警上。商品模型设计对了搜索和购物车都会很顺监控告警完善了很多问题能在用户察觉前就被处理掉。另外我会更早接入全链路压测和流量回放把潜在性能问题提前暴露出来。乐优商城这个项目走到后面最大的收获反而不是技术方案本身而是团队形成了“先想清楚流程边界再动手编码”的习惯。很多线上问题根源都出在业务规则没有被流程化代码只是表象。如果你也在做类似的电商项目建议在技术选型和编码之前先把用户主流程和异常分支都画清楚、想明白这个前期投入的回报远比后期熬夜修 Bug 要大得多。最后再说一点实操层面的感受商城项目务必把“幂等”和“对账”两个词刻在脑子里。分布式环境下超时重试、消息重复、回调乱序都是常态所有关键操作都要做到“重复执行不影响结果”同时用定时任务把异常数据捞回来。把这两点做好商城的稳定性就有了基本盘。