支付業(yè)務(wù)訂單系統(tǒng)分庫分表

支付系統(tǒng)中訂單業(yè)務(wù)最主要的查詢維度有四個：訂單、用戶、商家、運營。

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

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

B2B業(yè)務(wù)

設(shè)計到分庫分表字段的核心查詢業(yè)務(wù)：

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

一種分庫分表思路：

系統(tǒng)訂單號生成規(guī)則：通過將分庫分表的數(shù)據(jù)寫入到生成規(guī)則內(nèi)，這樣可以進行定位位置。

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

B2C業(yè)務(wù)

建議把訂單數(shù)據(jù)冗余一份，分買家?guī)旌唾u家?guī)?，?shù)據(jù)庫通過消息中間件或者其他同步工具進行異步更新，這種場景最好將買家?guī)斓姆制I(截取買家ID)和賣家?guī)?截取賣家ID)的分片鍵都包含在訂單ID中，這樣賣家相關(guān)的業(yè)務(wù)查詢訂單明細時，可以直接走賣家?guī)臁?/p>

綜合分析

如果是 2C 和 2B 業(yè)務(wù)綜合存在，建議進行業(yè)務(wù)拆分，沒有必要把數(shù)據(jù)全部放在同一個業(yè)務(wù)邏輯內(nèi)。

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

例如根據(jù)創(chuàng)建時間來進行分表：

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

總結(jié)：實際場景實際分析，沒有統(tǒng)一的方案。?