交易系统设计(2)-交易流程优化实践①

本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！

• 🚀 魔都架构师 | 全网30W技术追随者
• 🔧 大厂分布式系统/数据中台实战专家
• 🏆 主导交易系统百万级流量调优 & 车联网平台架构
• 🧠 AIGC应用开发先行者 | 区块链落地实践者
• 🌍 以技术驱动创新，我们的征途是改变世界！
• 👉 实战干货：编程严选网

2.1 正向流程

用户添加购物车分为：

• 登录态

  将商品、购买数量关联到用户ID

• 非登录态

  server端会创建用户临时token标识，除了关联商品记录外，还会将标识缓存到客户端。如果处于登录态，会将临时表的数据合并到购物车表。

新创建的订单会放入超时表（或发延时消息），由定时任务扫描记录，未付款超时执行订单关闭，释放库存。

购物车批量下单，若涉及多个店铺，需拆单

发货环节，若涉及多个商品，可能拆包分批发货，关联多个物流单

对恶意刷单，接入风控策略。

2.2 逆向流程

逆向流程有个重要的子域业务，人工介入平台。早期订单不多时可内部人工消化，随着业务量的快速增长，可考虑智能客服，或大众评审。

用户能整单或部分申请退款。

风控检测到订单存在风险会自动发起退款。

若使用优惠券，部分退款，要扣掉优惠券部分。

2.3经验技巧

① 在线库

交易订单分为在线库（只保留近三月的订单数据），超过三月且状态结束（交易成功、交易关闭）的订单会移到归档库，提高查询性能。

② 分库分表及查询

选择分表键，但查询维度很多：

0. 买家角度，查询我的订单列表，需按 buyer_id 查
1. 订单详情，需按 order_id 查
2. 卖家角度，查询 我的销售 列表，需按 seller_id 查

可惜订单分表只有一个分表键，如何满足多维度 SQL 操作呢？

一般基于买家维度来设计，如淘宝将订单号拆成两部分：

• 前面为全局唯一自增id
• 后面为用户id后六位

于是，case1、2的查询即可使用 buyer_id 或 order_id 的后 6 位作为分表键，若预期未来最大支持扩展100万张逻辑分表，对 1 000 000 取模，得到买家维度的订单分表的编号。

对case3卖家维度的订单查询，采用数据异构方式，按 seller_id 维度另外存储一份数据，可考虑 ES宽表维度查询设计，专供卖家。

③ 读多写少

大多业务读多写少，若访问性能开始瓶颈，考虑一主多从、读写分离等优化策略。

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