高并發(fā)下單主要包括以下幾個(gè)方面：分庫(kù)分表、多應(yīng)用實(shí)例全局唯一訂單號(hào)、數(shù)據(jù)庫(kù)連接、買家查詢訂單、賣家查詢訂單、擴(kuò)容問(wèn)題、業(yè)務(wù)拆分。

一、分庫(kù)分表

隨著電商系統(tǒng)訂單量的增長(zhǎng)，訂單管理系統(tǒng)開發(fā)數(shù)據(jù)庫(kù)的發(fā)展主要經(jīng)歷以下幾個(gè)步驟： 

- 1主-1從架構(gòu) ；

- 雙主-多從架構(gòu)，讀寫分離 ；

- 表分區(qū)，提高并發(fā) ；

- 分表，提高并發(fā) ；

- Master更換SSD ；

- 分庫(kù)，分表，提高并發(fā)；

分庫(kù)分表實(shí)現(xiàn)過(guò)程

電商系統(tǒng)訂單分成16個(gè)庫(kù)，每個(gè)庫(kù)64個(gè)表進(jìn)行存儲(chǔ)，總共1024個(gè)表，mysql單表性能超過(guò)千萬(wàn)級(jí)別會(huì)導(dǎo)致性能嚴(yán)重下降，假設(shè)按千萬(wàn)計(jì)算，最高可以存儲(chǔ)百億級(jí)訂單。

隨著存儲(chǔ)問(wèn)題的解決，但復(fù)雜度會(huì)隨著增加：

首先是多庫(kù)怎么保證生成的電商系統(tǒng)訂單號(hào)全局唯一； 

其次電商訂單管理系統(tǒng)查詢復(fù)雜度的增加； 

買家查詢電商訂單時(shí)，應(yīng)該去哪個(gè)庫(kù)哪個(gè)表里查找，賣家應(yīng)該去哪查； 

再大的存儲(chǔ)量，隨著數(shù)據(jù)量的增長(zhǎng)，終究是會(huì)遇到瓶頸，該怎么擴(kuò)容。

二、全局唯一訂單號(hào)

這里采用Twitter snowflake方案，全劇唯一ID生成由：時(shí)間戳+機(jī)器ID+自增序列（+userid后兩位），訂單的生成過(guò)程直接在應(yīng)用實(shí)例中生成，直接在內(nèi)存中計(jì)算，且計(jì)算過(guò)程分散到每臺(tái)應(yīng)用實(shí)例中，解決性能問(wèn)題，userid后兩位在后面解釋。

三、數(shù)據(jù)庫(kù)連接問(wèn)題

分庫(kù)分表后，要連接數(shù)據(jù)庫(kù)變的復(fù)雜起來(lái)，分為兩種電商方案：

1、jdbc直連

此種方式需要在應(yīng)用代碼中，自己計(jì)算訂單應(yīng)該進(jìn)入哪個(gè)庫(kù)，可取訂單的后兩位，先對(duì)庫(kù)16進(jìn)行取模，再對(duì)表64取模，從而確定。優(yōu)點(diǎn)是直連數(shù)據(jù)庫(kù)性能更好，缺點(diǎn)是代碼復(fù)雜度增加。

2、通過(guò)中間價(jià)連接

中間價(jià)可以使用阿里的mycat連接，具體使用查看mycat文檔。優(yōu)點(diǎn)：代碼實(shí)現(xiàn)簡(jiǎn)單，跟分庫(kù)前差不多。

3、買家查詢訂單

電商系統(tǒng)訂單成交后，買家需要查詢訂單的時(shí)候，只有userid，并不知道訂單存在哪個(gè)庫(kù)哪張表中，從每個(gè)庫(kù)每個(gè)表中遍歷一遍不現(xiàn)實(shí)。所以還要對(duì)訂單號(hào)進(jìn)行改進(jìn)，之前是：時(shí)間戳+機(jī)器ID+自增序列?，F(xiàn)在此訂單號(hào)的后面加上userid的后兩位，時(shí)間戳+機(jī)器ID+自增序列+userid后兩位。訂單入庫(kù)取模的后兩位即userid后兩位，即同一個(gè)買家的所有訂單都會(huì)存入同一個(gè)表中，通過(guò)此設(shè)計(jì)買家即可找到訂單號(hào)應(yīng)該在哪個(gè)表中。

4、賣家查詢訂單

賣家查詢訂單不能像買家一樣，賣家的訂單分散在訂單表的各個(gè)表中。賣家訂單需要在業(yè)務(wù)拆分過(guò)程中，將電商系統(tǒng)訂單按賣家維度存入到別的庫(kù)和表中。此維度不僅賣家可以查詢到對(duì)應(yīng)所有訂單，并且方便統(tǒng)計(jì)、分析。

5、擴(kuò)容問(wèn)題

由于此方案已經(jīng)不是單純的通過(guò)電商系統(tǒng)訂單號(hào)查找訂單，還需要通過(guò)userid查找訂單，其次是電商系統(tǒng)訂單具有時(shí)間特性，用戶查詢的大部分都是最近的訂單，3月前的訂單很少會(huì)查看，所以不適合進(jìn)行擴(kuò)容，特別適合遷移歷史數(shù)據(jù)，將3個(gè)月前的數(shù)據(jù)遷移到歷史數(shù)據(jù)庫(kù)中，從而解決容量增長(zhǎng)的問(wèn)題。

6、業(yè)務(wù)拆分

下電商系統(tǒng)訂單過(guò)程，業(yè)務(wù)極其復(fù)雜，不只是電商系統(tǒng)訂單號(hào)的生成插入等，還要減庫(kù)存、支付等一系列的操作。所以應(yīng)該通過(guò)消息隊(duì)列將業(yè)務(wù)進(jìn)行拆分，本步驟只做電商系統(tǒng)訂單生成的操作，通過(guò)消息隊(duì)列實(shí)現(xiàn)數(shù)據(jù)的最終一致性。

數(shù)商云全鏈數(shù)字化產(chǎn)品解決方案， 實(shí)現(xiàn)供應(yīng)鏈上中下游資源整合管理

--------

供應(yīng)鏈系統(tǒng) / 供應(yīng)商系統(tǒng) / B2B電商系統(tǒng) / 采購(gòu)系統(tǒng) / 渠道商系統(tǒng) / 經(jīng)銷商系統(tǒng)

0 費(fèi) 用 系 統(tǒng) 演 示

▼

作者：章紹龍 ，來(lái)源：CSDN ；

<數(shù)商云（www.zhimaihui.cn）提供專業(yè)的全鏈數(shù)字化產(chǎn)品以及解決方案，為企業(yè)級(jí)商家提供系統(tǒng)開發(fā)（多種模式電商平臺(tái)搭建：B2B/B2B2C/B2C/O2O/新零售等）、供應(yīng)商系統(tǒng)搭建及電商解決方案服務(wù)>