专栏首页微观技术电商交易系统核心技术

电商交易系统核心技术

前言

电商诞生已经有20多个年头了,从早期很多人的质疑、骗子、不接受、甚至肄业排斥、打压,到现在彻底融入我们生活的方方面面,并号称中国的 “新四大发明”,“认知教育”使命已经完成。人们足不出户,网上下个单,就可以在家坐等收包裹,确实是一种享受。

今天就跟大家聊聊电商技术里面最重要的交易部分

核心模块

  • 购物车
  • 下单
  • 付款
  • 库存
  • 优惠
  • 收获地址
  • 订单管理
  • 退款
  • 成交记录
  • 评价

随着业务的发展可能面临的问题

1、创业早期,人手资源都比较缺乏,讲究灵活策略,为了快速上线,通常会采用集中式系统架构。等后面业务稍微稳定些,再喘口气慢慢做系统架构衍化、升级。

2、电商业务比较特殊,贴近生活,特别是经过十几年的淘宝电商教育,人们对网上购物已经形成习惯,如果你做垂直电商、社区电商、生鲜电商,虽然是切入部分人群,但高频交易依然会产生海量数据,底层存储设计要提前预留扩展。

3、电商营销活动总是特别多,市场同学经常搞个大促、秒杀,要注意高并发流量设计

4、电商的业务玩法总是特别多,要学会抽离共性组件,模块化,采用流程引擎灵活满足不同业务诉求

5、古话说得好,船小好掉头。臃肿庞大的系统、复杂历史包袱,不但协同效率低下,而且稳定性、扩展性也比较差。“拆” 是不可避免的选择,按DDD设计思想,确定好限界上下文,拆分一系列子域,如:会员域、商品域、交易域、库存域、支付域、物流域、营销域等等。

当然,随着业务的日积月累,子域系统逐渐复杂起来,可能还需要进一步拆分子子域。所以说,“复杂的系统架构都是随着业务发展逐渐演化而来的!”

交易流程

1、正向流程

  • 用户添加购物车分为登录态和非登录态,登录态好理解,将商品及购买数量关联到用户id上。对于非登录态,server端会创建用户临时token标识,除了关联商品记录外,还会将标识缓存到客户端。如果处于登录态,会将临时表的数据合并到购物车表。
  • 新创建的订单会放入超时表,由定时任务扫描记录,未付款超时执行订单关闭,释放库存
  • 购物车批量下单,如果涉及多个店铺,会进行拆单
  • 发货环节,如果涉及多个商品,可能会拆包分批发货,关联多个物流单
  • 对于恶意刷单要接入风控处理

2、逆向流程

  • 逆向流程里有一个重要的子域业务,人工介入平台。早期订单不多时可以内部人工消化,随着业务量的快速增长,可以考虑智能客服,或者大众评审。
  • 买家可以整单或部分申请退款
  • 风控检测到订单存在风险会自动发起退款
  • 如果有使用优惠券,部分退款,要扣掉优惠券部分

经验技巧

1、任何事物都有自己的生命周期,透过现象直达本质,可以帮我们以较低成本解决很多难题。交易订单分为在线库(只保留近三个月的订单数据),对于超过三个月且状态结束(交易成功、交易关闭)的订单会移到归档库中,大大提高了查询性能。

2、电商平台一般发展比较迅猛,如果再搞点市场活动,订单数据是比较容易出现因为单个数据库表中的数据量过大而造成性能的瓶颈。如何选择分表键,买家uid、还是订单id、又或者是卖家uid,貌似都无法满足所有的业务场景。

可以参考淘宝的做法,规则最大化适用原则,订单号拆成两部分,前面为全局唯一自增id,后面为买家id的后六位,分表键按照买家uid的后6位来计算,未来最大支持扩展100万张逻辑分表。可以支持按订单id或买家uid来查询,至于卖家部分,采用数据异构方式,将卖家uid及订单id放入另一张数据表中。

3、大多数业务都是读多写少,如果访问性能开始出现瓶颈,可以考虑一主多从、读写分离等优化策略

主从存储间数据同步都是异步操作,如果延迟较大,很容易影响用户体验。对于实时性要求较高的业务,可以依赖主库,或者借助缓存。

4、系统拆分

基础业务逻辑下沉到服务,业务模型需要统一抽象,能支持定制扩展。比如,对不同规格优惠券原子性拆分、动作类型定义,数据重组。非核心数据可以考虑复合字段,数据异构化并考虑引入搜索,满足多维度查询。

Web 产品层专注表示逻辑和编排,可以借助 SPI 业务框架、流程引擎、规则引擎等这些基础业务框架,在业务支撑上做到了灵活可扩展。系统也做了比较合理的分层,每层只需要关心本层所需关注的能力即可。

5、复杂且较多外部RPC依赖,如何保证全局性的事务处理,最直接场景就是交易的下单。

  • 营销优惠券服务、库存服务、下单服务是分开部署。交易创建流程中,订单、券和库存的状态必须要保证一致性
  • 调用券/库存服务超时/失败,异步发消息通知回滚;复杂性可控
  • MQ 生产端发送失败,可以重试,消息框架要采用幂等性生产者 。消费端通过ACK 机制保证最终一致
  • 消除了二阶段提交等分布式事务框架的侵入性影响
  • 最后一步的数据库订单置为 “可见” 要采用事务性消息,保证一致性。

注意:也可能存在优惠券预冻结后,交易这边的服务器宕机了,废单消息没有发送成功。此时可以参考RocketMQ的回查机制,通过轮询任务,扫描出相关记录,反查订单状态,决定最终提交或回滚。

6、支付环节如何保证多节点间数据一致性。采用消息+异步任务补偿

  • 订单创建成功后,会自动拉起三方支付的收银台,待用户付款成功后,会通过回调页面或API接口的方式通知支付系统,有支付系统发送MQ消息
  • 交易任务系统,消费消息做订单状态、减库存、销量等字段更新
  • 如果处理失败,会插入补偿表,通过阶梯式的异步补偿任务,保证最终一致性

7、如果业务逻辑复杂,内部涉及大量的接口调用,串行调用等待时间较长,如果各个节点间没有依赖关系,可以考虑并行化处理。

8、尽可能使用缓存。既有本地缓存,也有分布式缓存。至于缓存使用注意问题可以参考之前的写的文章,《使用缓存必须注意的事项

大促活动时,提前对缓存预热,借助缓存的高性能抗住大部分访问压力。

本文分享自微信公众号 - 微观技术(weiguanjishu),作者:TomGE

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-02-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Spring boot常用注解收集

    无论是xml配置、java注解配置,都称为配置元数据,所谓元数据即描述数据的数据。元数据本身不具备任何可执行的能力,只能通过外界代码来对这些元数据解析后进行一些...

    用户7676729
  • 血泪教训,线程池引发的内存泄露

    最近由于业务需求使用到了线程池对数据进行异步处理,上线后系统正常运行了两天多突然收到了一波Full GC的告警,赶紧dump了堆信息并回滚了服务。分析dump文...

    用户7676729
  • 史上最全ThreadPoolExecutor梳理(上篇)

    Java是面向对象编程,万事万物皆对象,讲究池化技术,可以避免对象频繁的创建、销毁,浪费性能。线程池作为线程的复用利器,工作中都用过,可以说是非常非常重要。面试...

    用户7676729
  • 从SAP最佳业务实践看企业管理(85)-PP-ATO按订单装配

    麦当劳的汉堡如果出品三分钟还没有卖掉就会被废弃,因为虽然它没有变质,但口感已经变差。虽然有如此严格的规定,但麦当劳的货品扔的很少,这就是品控团队的功劳。团队的第...

    SAP最佳业务实践
  • 记一次edu站点从敏感信息泄露到getshell - 先知社区

    前言 2020-10-03报送edusrc,目前已修复。 本次渗透具有一定运气成分,且比较基础,各位师傅图个乐就好,有任何问题欢迎指出! 感谢墨渊团队的各个师傅...

    天钧
  • wordpress文章ID不连续

    2016-05-3023:03:51 发表评论 1,092℃热度 先说明,这个明显是强迫症才会搞这种累死人不的好处的活,当然,我也是这种人。当初 Typech...

    timhbw
  • anyproxy学习1-windows平台安装和抓手机app上https请求

    做接口测试肯定离不开抓包,目前比较流行的抓包工具是fiddler和charles,相信并不陌生。这里介绍一个阿里公司研发的一个抓包神器,只需打开web页面,就能...

    上海-悠悠
  • 互联网金融黑中介指南

    *本文作者:mcvoodoo,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。 互联网金融这些年热火朝天,稍大一点的集团旗下都有互金业务,甚至一些根本和...

    FB客服
  • TKE操作指南 - 使用TKE CVM容器集群的业务优势(七)

    2.用户可通过访问services IP或者ingress 域名直接访问容器应用。

    亮哥说TKE
  • Appium安卓和iOS开发环境安装

    Appium是移动端的自动化测试工具,类似于Selenium,利用它可以驱动Android,iOS等设备完成自动化测试,比如模拟点击,滑动,输入等操作....

    py3study

扫码关注云+社区

领取腾讯云代金券