聊聊电商系统中常见的9大坑！库存超卖、重复下单、物流单ABA...

做为一名程序员，发展方向大致可以分为两个方面：一个是业务架构，一个是技术架构（中间件方向）。

业务架构，取其核心关键词，主要是围绕这不同的业务场景、业务规则，完成业务系统的落地建设，为用户提供在线化的信息服务。

既然说到业务，那方向可就多了去了，如：出行、外卖、充电宝、O2O、内容、社交、生鲜、电商，不同的业务有不同的特点。

面对这么多的业务域，有没有通用技术经验可以抽取，让我们可以以一应百 。

这里，首推电商业务，电商系统的复杂性很高，对高并发 、高性能 、高可用 、高扩展 ，等方面要求很高。你在其他业务中可能遇到的问题，在电商系统中基本都会遇到。

作为开发，希望自己成为某几个业务领域的技术专家 ，最好能先精通电商领域 ，有很强的借鉴意义。对于你后续拓展熟悉其他业务领域的个性化玩法有很大帮助。

那么，电商领域的技术架构有哪些常见问题？

一、避免重复下单

用户快速点了两次 “提交订单”  按钮，浏览器会向后端发送两条创建订单的请求，最终会创建两条一模一样的订单。

解决方案：

解决方案就是采用幂等机制 ，多次请求和一次请求产生的效果是一样的。

方案一：

利用数据库自身特性 “主键唯一约束”，在插入订单记录时，带上主键值，如果订单重复，记录插入会失败。

操作过程：

• 引入一个服务，用于生成一个“全局唯一的订单号”
• 进入创建订单页面时，前端请求该服务，预生成订单ID
• 提交订单时，请求参数除了业务参数外，还要带上这个预生成订单ID

方案二：

前端通过js脚本控制，无法解决用户刷新提交的请求。另外也无法解决恶意提交。

不建议采用该方案，如果想用，也只是作为一个补充方案。

方案三：

前后约定附加参数校验。

当用户点击购买按钮时，渲染下单页面，展示商品、收货地址、运费、价格等信息，同时页面会埋上Token 信息，用户提交订单时，后端业务逻辑会校验token，有且匹配才认为是合理请求。

注意：同一个 Token 只能用一次，用完后立马失效掉。