做为一名程序员,发展方向大致可以分为两个方面:一个是业务架构,一个是技术架构(中间件方向)。
业务架构,取其核心关键词,主要是围绕这不同的业务场景、业务规则,完成业务系统的落地建设,为用户提供在线化的信息服务。
既然说到业务,那方向可就多了去了,如:出行、外卖、充电宝、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>
补充:
关于幂等的处理,更多解决方案可以看这两篇文章