电商交易订单业务数据库设计演进

图片由通义万相生成

交易订单业务

大白话: 交易订单业务是在线交易的核心业务单元 。交易其实就是用户从各个平台买东西，搜索到自己需要的商品，领优惠券，然后点击下单购买，再进行支付，卖家发货，买家确认收货这样的一个流程。

业务访问基础模型

从上图可知，交易链路涉及系统繁多，业务逻辑也非常复杂，最简化的说，从表存储往上看， 不管业务逻辑如何，只是涉及到读写纬度的访问逻辑:

写入:

1. 订单表承担 交易相关信息，订单号，买家id，卖家id，商品，支付状态，时间 等等写入。

读取

1. 订单号纬度查询 ，最简单的 售后时，客服根据订单号查询交易相关信息。
2. 买家纬度查询，基于用户id，手机号，昵称等查询买家的订单数据，比如用户登陆app 查看所有订单，待发货订单
3. 卖家纬度查询，基于卖家id，店铺id，卖家手机等等纬度查询卖家纬度的订单数据，比如统计双十一 某个商家的成交总量。

演进

任何产品和业务都是从 0 到1 ，然后逐步发展到1到100，到1w 甚至更高的业务量。随着数据量增加，业务对数据的存取使用更加复杂，首先要解决的是面对海量业务数据，如何解决 订单表的设计和数据存储。

本文介绍订单表的设计相关事项，其实还有其他问题，比如 热点大卖家，海量数据存储成本问题，如何解决数据查询和归档，等等。

单表

电商业务刚刚开始发展时，订单表是以单表存储的。因为数据量相对较少，几百万w ，甚至几千万的量级。单个表就能满足 买卖家纬度的各种查询，随着业务的不断发展，单表的问题逐步凸显出来。

问题

1. 单表数据量越来越大，涉及聚合查询性能越差。
2. 单表 DDL 维护困难，锁表，或者copy表的方式 耗时长而且性能抖动。(如果使用 MySQL 8.0 会好很多。)

分库分表

为了应对海量的数据增长，我们需要对业务数据进行分库或者分库分表操作。此时业务面临的问题在于: 如何合理设置合理的分表规则，拆分规则 才能满足业务对数据的访问需求。

我们通常使用的分表规则是选取业务表的某一列作为分表键进行哈希打散到各个数据库中。基于前面的业务访问情况，我们可以选择的分表键键有买家id，卖家id，订单号。

比如 交易数据库计划分128个库， 分2048张分表。

基于买家 id

对于买家id buy_id 取模 比如 buy_id%2048%128 ，先分表，然后再落到不同的分库里面。

注意 这里 buy_id%2048%128 是直接取模2048,再分配到 128个分库里面 ，其实关于取模可以加上业务逻辑，比如如果提前规划业务多活的话，就要取更大范围比如 10000, 将分表键范围锁定 0-9999，比取模 2048 多4倍的，将数据更均匀的打散到不同的数据库中。

优点：

1. 数据相对均匀分布，还说一般没有超级买家的说法，每天购物100笔，一年也才30w条记录，如果真的有，要对该用户提供
2. 支持查询单个交易 类似 K-V 点查和 范围查询。

缺点:

1. 不能满足卖家纬度的查询和分析。
2. 不能满订单号纬度的查询。

基于卖家 id

对于卖家id进行 取模分表 ， seller_id%2046%128

缺点：

1. 卖家会有 超大卖家的说法，比如天猫的头部商家 小米，苏宁等等，每年双十一都有上百万的订单量，按照年计算会更大，从数据存储角度来看会有严重的数据倾斜问题。
2. 不能满订单号纬度/买家 id 的查询。

订单号

基于 进行订单号取模，order_no%2046%128

优点:

1. 数据分布均匀，不存在热点问题。根据订单号获取订单相关数据，类似K-V查询 ，一般都是点查。

缺点：

1. 无法根据买/卖家id维度进行数据分析和查询。

最优解

1. 基于 MySQL 架构，上面三种场景无法再同一套库中完成，需要创建2个数据库: 买家库和卖家库,数据相同，但是查询纬度不一样。所有的业务数据只在买家端写入，买家订单信息和商家修改订单以订单维度写入买家库。然后通过 DTS 等CDC 工具同步 买家库的binlog 到卖家库。(当然 业务逻辑上可以有订单交易服务中心统一控制 数据的访问接口)
2. 买家卖家是两个纬度，但是订单号 和 买家 是同一个写入源 ，买家从购物车,商品页面结算的时候，订单号和买家id 一起写入同一行记录。因此可以同时满足基于买家id 和 订单号查询。
3. 对订单号进行定制，订单号由订单号 sequence(seq_order_id ) + 买家id ( buyer_id)组成。只是 订单号的取模逻辑和 买家id 需要保持一致， 末尾四个数字。比如 买家id 的后四位 1024 ， 订单 id 的后四位也可以是 1024。(也可以由分片规则指定1024 在订单号中具体的位置)

总结

虽然说本文是说的订单数据设计，但是也适用于其他业务场景，从小业务量到海量数据的数据库演进。

另外良好的IT,业务架构是演进出来的,并非是一步到位，就能达到完美的架构。