电商系统架构，常见的 9 个大坑 ，库存超卖，重复下单，物流单ABA

大家好，我是Tom哥~

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

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

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

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

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

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

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

一、避免重复下单

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

解决方案：

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

方案一：

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

操作过程：

• 引入一个服务，用于生成一个“全局唯一的订单号”

• 进入创建订单页面时，前端请求该服务，预生成订单ID

• 提交订单时，请求参数除了业务参数外，还要带上这个预生成订单ID

方案二：

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

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

方案三：

前后约定附加参数校验。

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

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

<form action="/add-name-v2" method="post">
    {% csrf_token %}
    <input type="text" name="name">
    <input type="submit" value="提交">
</form>

补充：

关于幂等的处理，更多解决方案可以看这两篇文章

• 高并发下如何保证接口的幂等性？

• 幂等设计，都有哪些技术方案？

二、订单快照，减少存储成本

商品信