前言
从之前文章了解到一个简单的订单系统订单数据只需要一张简单的订单表就能够搞定,但随着业务的发展,单表会变得会越来越臃肿,越来越不容易维护。此时我们就需要对订单进行分表操作(注意此处的分表仅仅是业务层面的分表,不涉及高并发)。来方便日后订单系统的迭代开发。与订单中心交互最多的自然是业务系统和支付系统。接下来这篇文章带你如何切割订单表结构。
业务分表
- 我们设计订单表结构的时候,存入订单快照一般有俩种方式,第一种如之前所说的简易版本放入一个extend字段,但这样会极其不利于查询和统计,例如你要按商品维度,或者收货地址等等业务属性去查询订单的时候会直接让你崩溃,如果单独存入表字段那后续如果查询的条件越来越多,例如商品可能有商品名称,火车票有车次,飞机票有航班等等,那只会让你的表结构变得越来越庞大直至你变得难以忍受。既然这样我们可以设计订单系统的时候为何不直接将订单,将它的业务属性和基础属性分开如下图一样
- 基础订单根据orderType将订单分为几大类,每一类业务订单表结构基本一致。各类业务之间互不影响,用时下的职场话说,就是把订单表扁平化管理,基础订单是领导,下面各类业务订单表是小弟,每个小弟无论是扩展还是更新都对其它的不会有影响
- 订单查询时用宽表查询,订单插入和更新时订单系统要保证同步更新
- 如果业务用户量够大可以考虑按照表结构把订单系统拆分,底层业务系统处理基础的状态变换,数据更新,业务订单系统专门对接业务系统以及控制流程。
金额类分表
- 订单除了记订单本身的属性和业务属性之外,金额属性也是必不可少的一环,例如支付金额,退款金额等等，当你的订单支付方式变多，你可能会要增加支付渠道,支付方式字段,当订单支持积分等下单时优惠类金额时你可能也需要记录,当订单支持优惠券支付时优惠金额时你可能又要记录。把订单金额类信息拆分出来专门对接支付系统是十分有必要的
- 这样订单基础信息表会变得更加纯粹,支付后与支付系统的交互也会变得更加干净,能更方便查询订单支付类信息。
- 同样查询时也可以宽表查询,但笔者不建议,对于高频的订单列表接口一般列表只需要展示一个订单金额就够了,查询详情时再进行金额订单类信息查询。当然如果其它系统对订单系统有类似需求,也可以提供一个宽表查询的接口
总结
- 本篇文章主要介绍了订单的分表,对基础表订单进行了调整,其实当表结构发生变更时,一般系统架构也会发生变更。例如订单集群分为底层订单和业务订单部分,根据每条业务线不同的流水量去决定服务的资源。例如订单和支付中心的交互模式都需要变换。笔者这里借用以前的一张图分表之后整个模块可以这样设计。
