订单系统分表

订单和支付系列目录

前言

• 从以前文章了解到一个简易版订单系统订单数据只须要一张简单的订单表就可以搞定,但随着业务的发展,单表会变得会愈来愈臃肿,愈来愈不容易维护。此时咱们就须要对订单进行分表操做(注意此处的分表仅仅是业务层面的分表,不涉及高并发)。来方便往后订单系统的迭代开发。与订单中心交互最多的天然是业务系统和支付系统。接下来这篇文章带你如何切割订单表结构。

业务分表

咱们设计订单表结构的时候,存入订单快照通常有俩种方式

• 第一种如以前所说的简易版本放入一个extend字段,但这样会极其不利于查询和统计,例如你要按商品维度,或者收货地址等等业务属性去查询订单的时候会直接让你崩溃
• 单独存入表字段那后续若是查询的条件愈来愈多,例如商品可能有商品名称,火车票有车次,飞机票有航班等等,那只会让你的表结构变得愈来愈庞大直至你变得难以忍受。既然这样咱们能够设计订单系统的时候为什么不直接将订单,将它的业务属性和基础属性分开以下图同样

• 基础订单根据orderType将订单分为几大类,每一类业务订单表结构基本一致。各种业务之间互不影响,用时下的职场话说,就是把订单表扁平化管理,基础订单是领导,下面各种业务订单表是小弟,每一个小弟不管是扩展仍是更新都对其它的不会有影响
• 订单查询时用宽表查询,订单插入和更新时订单系统要保证同步更新
• 若是业务用户量够大能够考虑按照表结构把订单系统拆分,底层业务系统处理基础的状态变换,数据更新,业务订单系统专门对接业务系统以及控制流程。

金额类分表

• 订单除了记订单自己的属性和业务属性以外,金额属性也是必不可少的一环,例如支付金额,退款金额等等，当你的订单支付方式变多，你可能会要增长支付渠道,支付方式字段,当订单支持积分等下单时优惠类金额时你可能也须要记录,当订单支持优惠券支付时优惠金额时你可能又要记录。把订单金额类信息拆分出来专门对接支付系统是十分有必要的

• 这样订单基础信息表会变得更加纯粹,支付后与支付系统的交互也会变得更加干净,能更方便查询订单支付类信息。
• 一样查询时也能够宽表查询,但笔者不建议,对于高频的订单列表接口通常列表只须要展现一个订单金额就够了,查询详情时再进行金额订单类信息查询。固然若是其它系统对订单系统有相似需求,也能够提供一个宽表查询的接口

总结

• 本篇文章主要介绍了订单的分表,对基础表订单进行了调整,其实当表结构发生变动时,通常系统架构也会发生变动。例如订单集群分为底层订单和业务订单部分,根据每条业务线不一样的流水量去决定服务的资源。例如订单和支付中心的交互模式都须要变换。笔者这里借用之前的一张图分表以后整个模块能够这样设计。