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

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

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

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

B2B業(yè)務(wù)

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

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

一種分庫分表思路：

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

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

B2C業(yè)務(wù)

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

綜合分析

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

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

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

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

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