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

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

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

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

B2B業(yè)務(wù)

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

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

一種分庫(kù)分表思路：

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

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

B2C業(yè)務(wù)

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

綜合分析

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

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

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

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

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