支付業務訂單系統分庫分表

支付系統中訂單業務最主要的查詢維度有四個：訂單、用戶、商家、運營。

從查詢數據庫字段的角度來講，B2B、B2C等模式：

• 商戶編號+商戶訂單號查詢，商戶編號+商戶訂單號屬于唯一性約束。
• 商戶編號查詢，例如商戶后臺查詢，運營后臺查詢。
• 系統訂單號查詢，訂單系統自身生成，全局唯一性約束。
• 用戶編號查詢，例如電商業務，查詢自己的訂單
• 系統訂單號+用戶編號查詢，例如用戶精準查詢個人訂單
• 無條件查詢，例如運營后臺查詢

B2B業務

設計到分庫分表字段的核心查詢業務：

• 商戶編號+商戶訂單號查詢，商戶編號+商戶訂單號屬于唯一性約束。
• 商戶編號查詢，例如商戶后臺查詢，運營后臺查詢。
• 系統訂單號查詢，訂單系統自身生成，全局唯一性約束。

一種分庫分表思路：

系統訂單號生成規則：通過將分庫分表的數據寫入到生成規則內，這樣可以進行定位位置。

商戶編號規則：取商戶編號后4位做分片鍵，進行hash取模。

B2C業務

建議把訂單數據冗余一份，分買家庫和賣家庫，數據庫通過消息中間件或者其他同步工具進行異步更新，這種場景最好將買家庫的分片鍵(截取買家ID)和賣家庫(截取賣家ID)的分片鍵都包含在訂單ID中，這樣賣家相關的業務查詢訂單明細時，可以直接走賣家庫。

綜合分析

如果是 2C 和 2B 業務綜合存在，建議進行業務拆分，沒有必要把數據全部放在同一個業務邏輯內。

訂單數據有個比較特殊的點，隨著時間的推進，大量的數據會變成冷數據，使用率會降低。還有一種根據創建時間來進行分表是一個不錯的選擇。所以分庫分表其實沒有統一的方案，要根據業務進行詳細的設計。

例如根據創建時間來進行分表：

• 時間差，是不是要冗余查詢，因為支付訂單的時效性來講，是不是可以默認查詢2天的數據。
• 支付訂單是存在有效期的，比如訂單過期，所以是不是可以設置規則，接口只能查詢當日的數據。
• 商戶后臺可以通過一些數據同步手段，例如 canal 同步到 es 等等手段。

總結：實際場景實際分析，沒有統一的方案。?