聊聊二手商城的架构：我们如何解决了“立即购买”的库存锁定，以及为什么购物车是个“坑”？

聊聊二手商城的架构：我们如何解决了“立即购买”的库存锁定，以及为什么购物车是个“坑”？

大家好，我是小巫。最近在搞一个二手闲置商城的项目，过程中踩了不少坑，也沉淀了一些思考，想借这个机会和大家聊聊。核心是两个经典问题：

1. “立即购买”的并发库存锁定怎么处理才优雅？
2. 二手商城，到底需不需要“购物车”这个模块？

一、直面“立即购买”的并发难题：从刚性锁定到柔性预扣减

我们项目的初期架构比较直接。用户点击“立即购买”，后端直接在数据库层面锁定商品，并生成一个5分钟的待支付订单。

听起来没问题？但黑盒测试时，bug马上就现形了：

我朋友点击购买后不支付，只是想看看流程。结果在这5分钟里，别说其他用户了，连我自己都无法访问这个商品详情，页面直接卡住或报错。如果并发量上来，几十个人同时这么操作，那服务器估计就直接“GG”了。

这其实是一个典型的反模式。直接锁数据库，尤其是在高并发的交易场景下，不仅会造成性能瓶颈和死锁，用户体验更是灾难。

我们的解决思路：放弃DB刚性锁，拥抱“缓存预扣减”。

流程改造如下，基本思想就是把压力从DB扛到Redis：

1. 前端请求：用户点击“立即购买”，携带 商品ID、用户ID 请求订单服务。

2. 订单服务：

   • 绝不碰数据库。先去查商品服务，拿到价格、名称等信息。

   • 核心来了

     ：直接请求Redis，用原子操作（比如

     DECR
     

     ）检查并扣减库存。我们用类似

     product:stock:商品ID
     

     这样的key。

     • 如果Redis返回值>=0，说明库存足够，预扣减成功。
     • 如果<0，说明手慢了，库存没了。赶紧把刚才减掉的库存再加回去（INCR），然后给前端返回“商品已被抢光”的提示。

3. 生成临时订单：预扣减成功后，生成一个带时效性（比如10分钟）的临时订单，返回订单号给前端。

4. 前端跳转：前端拿到订单号，跳转到支付确认页，页面上搞个倒计时，催用户赶紧付款。

后续流程闭环：

• 支付成功：订单服务收到支付回调，将临时订单状态改为“已支付”，然后发送一个消息（用RabbitMQ或RocketMQ）通知商品服务，去真正地扣减数据库里的物理库存。这是最终一致性的体现。
• 支付超时/取消：我们的订单服务会有一个定时任务（比如用xxl-job或ScheduledExecutorService），每分钟扫描那些“待支付且已超时”的订单。一旦发现，就执行取消逻辑，并发送消息，让商品服务把之前在Redis里预扣减的库存加回去。

这套组合拳下来，既解决了高并发下的性能问题，也避免了恶意锁定，用户体验也流畅了很多。

二、二手商城需要购物车吗？我的答案：不需要，而且是个坑。

解决了“立即购买”的问题后，团队里又冒出一个经典问题：“咱们要不要上个购物车功能？”

在传统B2C电商里，这根本不是问题。但在二手商城，我的观点很明确：千万别！

核心原因就四个字：商品唯一 (Stock = 1)。

因为这个属性，购物车会让你陷入一个两难的“锁定困境”：

• 选择1：加入购物车就锁库存
  • 卖家得急死：买家A把商品加了购物车，犹豫10分钟不付款。这期间，真正想秒付的买家B、C、D只能干瞪眼。卖家错失了N个成交机会。
  • 体验极差：更别提恶意用户用脚本把热门商品全加一遍购物车，卖家今天就别想开张了。
• 选择2：加了不锁库存（谁先付款算谁的）
  • 买家直接心态爆炸：“我明明把东西放进购物车了，怎么付钱的时候告诉我没了？！” 这种“虚假的安全感”带来的挫败感，足以让用户卸载App。

看到了吗？无论你怎么选，都会同时得罪买家和卖家。这种吃力不讨好的功能，我们为什么要做？

三、那该怎么做？二手商城的“新三样”

放弃购物车，不代表我们放弃了相应的功能体验。我们只是用了更适合二手场景的“新三样”来替代它：

功能模块	目的 & 解决方案
立即购买 (Buy Now)	替代“直接结算”。这是二手交易最高效的路径。它向用户传递了最清晰的心智模型：“先付先得，手慢无”。公平，直接。
收藏夹 / 喜欢 (Favorites / Likes)	替代“稍后购买”。这才是二手场景下真正的“购物车”。用户可以收藏、追踪、比较，但平台和卖家没有任何库存锁定的心智负担。它纯粹是一个方便用户的工具。
打包购买 (Bundling)	替代“合并订单”。这是为“我想在同一个卖家这儿买好几样东西省点邮费”这个精准场景量身定做的。它不是一个跨店铺的通用购物车，而是一个与单个卖家的互动工具，逻辑清晰，目的明确。

看看头部玩家：国内的闲鱼，国外的Poshmark、Depop，它们的核心体验都是围绕这“新三样”来构建的，你基本找不到一个传统意义上的购物车。

写在最后

技术架构最终是为业务模式服务的。传统电商的成熟方案，不能无脑照搬到二手领域。搞清楚二手商品“唯一性”这个核心前提，很多设计问题自然就有了答案。

以上是我们项目里的一些思考和实践，希望能给大家带来点启发。也欢迎大家在评论区聊聊你们的看法！