【万字长文】说说电商系统常见的 9 个大坑，人麻了……

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

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

既然说到业务，那方向可就多了去了，如：出行、外卖、充电宝、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>

 

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

商品信息是可以修改的，当用户下单后，为了更好解决后面可能存在的买卖纠纷，创建订单时会同步保存一份商品详情信息，称之为订单快照。

同一件商品，会有很多用户会购买，如果热销商品，短时间就会有上万的订单。如果每个订单都创建一份快照，存储成本太高。另外商品信息虽然支持修改，但毕竟是一个低频动作。我们可以理解成，大部分订单的商品快照信息都是一样的，除非下单时用户修改过。

如何实时识别修改动作是解决快照成本的关键所在。我们采用摘要比对的方法‍。创建订单时，先检查商品信息摘要是否已经存在，如果不存在，会创建快照记录。订单明细会关联商品的快照主键。

public class DigestTest {
    public static void encodeStr(String data) {
        String encodeS = DigestUtils.md5Hex(data);
        System.out.println(encodeS);