訂單系統分表

訂單和支付系列目錄

前言

• 從以前文章瞭解到一個簡易版訂單系統訂單數據只須要一張簡單的訂單表就可以搞定,但隨着業務的發展,單表會變得會愈來愈臃腫,愈來愈不容易維護。此時咱們就須要對訂單進行分表操做(注意此處的分表僅僅是業務層面的分表,不涉及高併發)。來方便往後訂單系統的迭代開發。與訂單中心交互最多的天然是業務系統和支付系統。接下來這篇文章帶你如何切割訂單表結構。

業務分表

咱們設計訂單表結構的時候,存入訂單快照通常有倆種方式

• 第一種如以前所說的簡易版本放入一個extend字段,但這樣會極其不利於查詢和統計,例如你要按商品維度,或者收貨地址等等業務屬性去查詢訂單的時候會直接讓你崩潰
• 單獨存入表字段那後續若是查詢的條件愈來愈多,例如商品可能有商品名稱,火車票有車次,飛機票有航班等等,那隻會讓你的表結構變得愈來愈龐大直至你變得難以忍受。既然這樣咱們能夠設計訂單系統的時候爲什麼不直接將訂單,將它的業務屬性和基礎屬性分開以下圖同樣

• 基礎訂單根據orderType將訂單分爲幾大類,每一類業務訂單表結構基本一致。各種業務之間互不影響,用時下的職場話說,就是把訂單表扁平化管理,基礎訂單是領導,下面各種業務訂單表是小弟,每一個小弟不管是擴展仍是更新都對其它的不會有影響
• 訂單查詢時用寬表查詢,訂單插入和更新時訂單系統要保證同步更新
• 若是業務用戶量夠大能夠考慮按照表結構把訂單系統拆分,底層業務系統處理基礎的狀態變換,數據更新,業務訂單系統專門對接業務系統以及控制流程。

金額類分表

• 訂單除了記訂單自己的屬性和業務屬性以外,金額屬性也是必不可少的一環,例如支付金額,退款金額等等，當你的訂單支付方式變多，你可能會要增長支付渠道,支付方式字段,當訂單支持積分等下單時優惠類金額時你可能也須要記錄,當訂單支持優惠券支付時優惠金額時你可能又要記錄。把訂單金額類信息拆分出來專門對接支付系統是十分有必要的

• 這樣訂單基礎信息表會變得更加純粹,支付後與支付系統的交互也會變得更加乾淨,能更方便查詢訂單支付類信息。
• 一樣查詢時也能夠寬表查詢,但筆者不建議,對於高頻的訂單列表接口通常列表只須要展現一個訂單金額就夠了,查詢詳情時再進行金額訂單類信息查詢。固然若是其它系統對訂單系統有相似需求,也能夠提供一個寬表查詢的接口

總結

• 本篇文章主要介紹了訂單的分表,對基礎表訂單進行了調整,其實當表結構發生變動時,通常系統架構也會發生變動。例如訂單集羣分爲底層訂單和業務訂單部分,根據每條業務線不一樣的流水量去決定服務的資源。例如訂單和支付中心的交互模式都須要變換。筆者這裏借用之前的一張圖分表以後整個模塊能夠這樣設計。