做为一名程序员,发展方向大致可以分为两个方面:一个是业务架构,一个是技术架构(中间件方向)。
业务架构,取其核心关键词,主要是围绕这不同的业务场景、业务规则,完成业务系统的落地建设,为用户提供在线化的信息服务。
既然说到业务,那方向可就多了去了,如:出行、外卖、充电宝、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);
}
public static void main(String[] args) {
String data = "网销投连险是保险公司的一款保险产品