电商交易系统核心技术

点击上方“ 微观技术 ”，选择“ 设为星标 ”

回复” 架构 “免费看一线大厂架构资料

前言

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

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

核心模块

• 购物车

• 下单

• 付款

• 库存

• 优惠

• 收获地址

• 订单管理

• 退款

• 成交记录

• 评价

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、尽可能使用缓存。既有本地缓存，也有分布式缓存。至于缓存使用注意问题可以参考之 前的写的文章，《 使用缓存必须注意的事项 》

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

END

我们热衷于收集&分享高并发、系统架构、微服务、消息中间件、 RPC框架、高性能缓存、搜索、分布式数据框架、分布式协同服务、分布式配置中心、中台架构、领域驱动设计、系统监控、系统稳定性等技术知识。

https://github.com/aalansehaiyang/technology-talk

活到老、学到老，用技术普惠世界

关注 【微观技术】

共创世界，探寻人生价值