電商平臺(tái)通用取貨碼設(shè)計(jì)

一、背景

隨著O2O線上線下業(yè)務(wù)的不斷擴(kuò)展，電商平臺(tái)也在逐步完善交易側(cè)相關(guān)的產(chǎn)品功能。在最近的需求版本中，業(yè)務(wù)方為進(jìn)一步提升用戶的使用體驗(yàn)，規(guī)劃了取貨碼生成及訂單核銷相關(guān)邏輯，目的是讓線上的用戶在付完款之后能夠到店取貨或者安排導(dǎo)購(gòu)派送。

日常生活中，我們對(duì)取貨碼、核銷這類功能使用的經(jīng)歷大部分都來(lái)自：看電影前取票、吃飯后出示券碼、快遞柜取包裹等等，它們都有一些類似的特點(diǎn)，比如：

• 取貨碼長(zhǎng)度相對(duì)較短，比起動(dòng)輒十幾二十位訂單號(hào)，幾位的數(shù)字碼更方便記憶和輸入；
• 除了數(shù)字取貨碼，還提供二維碼，方便終端進(jìn)行掃描并核銷。

取貨碼使用起很簡(jiǎn)單，然而像“冰山”一樣，隱藏在簡(jiǎn)單外表下面卻需要嚴(yán)謹(jǐn)?shù)脑O(shè)計(jì)和細(xì)致的邏輯，可以說(shuō)麻雀雖小五臟俱全。本文介紹的設(shè)計(jì)也比較有趣，而且按此思路可以實(shí)現(xiàn)市面上大多數(shù)核銷類券碼的生成，同時(shí)也能滿足業(yè)務(wù)的SaaS化，算是一個(gè)相對(duì)通用的能力，在此把整個(gè)設(shè)計(jì)分享給大家。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

二、簡(jiǎn)單系統(tǒng)的單表業(yè)務(wù)

如果業(yè)務(wù)的體量不大，店鋪流量比較小，未形成平臺(tái)的規(guī)模，比如給個(gè)體經(jīng)營(yíng)者使用的系統(tǒng)。那么取貨碼或券碼的實(shí)現(xiàn)就比較簡(jiǎn)單，跟訂單共享一張大橫表或者使用擴(kuò)展表跟訂單進(jìn)行關(guān)聯(lián)就行了，這個(gè)階段也無(wú)需做過(guò)度設(shè)計(jì)。

表的設(shè)計(jì)如下圖：

不過(guò)需要注意的是一般訂單號(hào)都是比較長(zhǎng)的，通常都在十幾二十位（當(dāng)然也有比較短的訂單號(hào)，如果訂單號(hào)比較短，取貨碼也可采用訂單號(hào)）我們假設(shè)訂單號(hào)18位，取貨碼8位，即訂單號(hào)的取值范圍遠(yuǎn)大于取貨碼，那么在訂單號(hào)的生命周期內(nèi)，取貨碼是有很大幾率存在重復(fù)的。解決起來(lái)相對(duì)簡(jiǎn)單，我們只需要保證在任意條件下，未核銷 狀態(tài)的數(shù)字碼不重復(fù)即可，也即已核銷的數(shù)字碼可以回收利用。

那么取貨碼的生成邏輯就很清晰了，下面用偽代碼模擬真實(shí)的實(shí)現(xiàn)邏輯：

偽代碼實(shí)現(xiàn)

for(;;){
step1獲取隨機(jī)碼：Stringcode=this.getRandomCode();
step2執(zhí)行SQL：SELECTCOUNT(1)FROMorder_mainWHEREcode=${code}ANDwrite_off_status=0;
step3判斷是否可以插入：if(count>0){continue;}
step4執(zhí)行數(shù)據(jù)寫入：UPDATEorder_mainSETcode=${code},qr_code=${qrCode},write_off_status=0WHEREorder_no=${orderNo}
}

注意： 這里step2和step4不是原子操作，存在并發(fā)問(wèn)題，實(shí)際應(yīng)用中最好使用分布式鎖，把操作鎖住。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

三、 復(fù)雜平臺(tái)的分庫(kù)分表業(yè)務(wù)

通過(guò)簡(jiǎn)單的單表設(shè)計(jì)，我們能管窺一斑，了解取貨碼大致的實(shí)現(xiàn)邏輯。不過(guò)我們?cè)诎押?jiǎn)單方案往大型項(xiàng)目上進(jìn)行落地的時(shí)候，就需要考慮很多方面，設(shè)計(jì)也需要更精巧。SaaS化的電商平臺(tái)會(huì)比簡(jiǎn)單的單表業(yè)務(wù)復(fù)雜很多，重點(diǎn)體現(xiàn)在：

1. SaaS 產(chǎn)品涉及的店鋪很多且訂單量大，需要設(shè)計(jì)大容量存儲(chǔ)，所以訂單表基本使用分庫(kù)分表，顯然作為訂單附屬的取貨碼表也得使用相同的策略；
2. B端和C端用戶的體驗(yàn)非常重要，服務(wù)端接口的設(shè)計(jì)需要充分考慮魯棒性，完善最基本的重試及容錯(cuò)能力；
3. 不同業(yè)務(wù)方對(duì)于取貨碼的要求可能不太一樣，取貨碼的設(shè)計(jì)需要具有通用性以及個(gè)性化的配置屬性。

3.1 詳細(xì)設(shè)計(jì)

取貨碼表的設(shè)計(jì)推薦使用和訂單一致的分庫(kù)分表策略，好處是：

1. 和訂單一樣，支撐海量訂單行的存儲(chǔ)；
2. 方便利用同樣的分庫(kù)分表因子進(jìn)行查詢（例如：open_id、member_id）。

在考慮落地實(shí)現(xiàn)上，我們遇到了第一個(gè)討論的點(diǎn)，那就是取貨碼是做到“門店唯一 ”還是“全局唯一 ”？

3.2 門店唯一方案

剛開(kāi)始考慮使用類似飯館取餐碼類似的邏輯，保證取貨碼在各自門店保持唯一就行了。類似如下圖交互，圖中用戶A和用戶B持有相同的取貨碼，用戶A、B分別去他們對(duì)應(yīng)的店鋪完成核銷，整個(gè)交易過(guò)程就結(jié)束了。但是這得保證用戶A和B能正確地在各自訂單歸屬的店鋪完成核銷，顯然這個(gè)方案是帶有風(fēng)險(xiǎn)的！

下圖所示的這種情況下，用戶A、B也能正常核銷，不過(guò)串單了，原本屬于用戶A的訂單被用戶B核銷了。這種問(wèn)題出現(xiàn)的本質(zhì)原因在于純粹的數(shù)字碼無(wú)法帶有用戶的標(biāo)識(shí)，雖然可以在核銷前做人為的核驗(yàn)身份來(lái)避免，但依然屬于高風(fēng)險(xiǎn)的系統(tǒng)設(shè)計(jì)，所以門店唯一方案不可取！

3.3 全局唯一方案

全局唯一方案風(fēng)險(xiǎn)小，但實(shí)現(xiàn)難度稍高一點(diǎn)。核心問(wèn)題在于如何判定隨機(jī)生成的取貨碼是全局唯一的，當(dāng)然如果系統(tǒng)本身依賴ES這類存儲(chǔ)介質(zhì)，可以在插入前先查詢ES，不過(guò)查詢和寫入ES對(duì)于實(shí)時(shí)性接口來(lái)說(shuō)稍微有點(diǎn)重，沒(méi)有直接查庫(kù)表來(lái)得直接。假設(shè)某業(yè)務(wù)方分成了4個(gè)庫(kù)4張表，總計(jì)16表，取貨碼的長(zhǎng)度確定為8位，那如何在多庫(kù)多表的Mysql中查詢并保證全局唯一呢？遍歷表的方式肯定不可??！

為解決上述的疑問(wèn)，我們?cè)谠O(shè)計(jì)的時(shí)候可以在取貨碼的編排上做點(diǎn)文章，如下步驟做具體詳解：

步驟①： 可以將8位的取貨碼分成兩個(gè)區(qū)域，“隨機(jī)碼區(qū)域”+“庫(kù)表位置” ，下圖示例：

步驟②： 隨機(jī)碼區(qū)域暫不介紹，我們來(lái)看下2位庫(kù)表如何映射到4庫(kù)4表組成的16張表中。

這里也有兩套方案：

【方案一】 可以選擇2位庫(kù)表的首位作為庫(kù)編號(hào)，末位作為表編號(hào)。好處是映射較為簡(jiǎn)單，但是容量不夠大，如果分的庫(kù)或表>9，擴(kuò)展就會(huì)有點(diǎn)麻煩。如下圖，我們把末尾“12”邏輯映射到了“1庫(kù)的編號(hào)為2的表”；

【方案二】 將4庫(kù)4表二維結(jié)構(gòu)轉(zhuǎn)成一維，以0為初始值進(jìn)行遞增，(0庫(kù), 0表) → 00, (0庫(kù), 1表) → 01... , (3庫(kù), 3表) → 15。好處是容量變大了，最大支持99張表，不受庫(kù)或表單一條件的限制，缺點(diǎn)就是映射邏輯寫起來(lái)麻煩點(diǎn)，不過(guò)這不是問(wèn)題。

取貨碼經(jīng)過(guò)簡(jiǎn)單編排，我們完成了取貨碼的到庫(kù)表的映射邏輯，解決了取貨碼存取的問(wèn)題。其實(shí)仔細(xì)想想，關(guān)于全局唯一的問(wèn)題其實(shí)也解決掉了，我們只要保證前6位隨機(jī)碼 在單表里保證唯一即可，理論上支持單表在未核銷狀態(tài)下范圍為：000000 ~ 999999條記錄，容量是足夠的。關(guān)鍵我們把多庫(kù)多表的查詢就簡(jiǎn)化成了只跑一個(gè)SQL，效率大大提升。

3.4 方案落地遇到的問(wèn)題

既然本篇是介紹SaaS化的完整方案，在落地的時(shí)候或多或少會(huì)遇到一些問(wèn)題，這邊介紹三個(gè)實(shí)際遇到的典型問(wèn)題，并給出一些解決方案：

【問(wèn)題一】 使用Math.random()生成的6位隨機(jī)碼和表里的重復(fù)了，如何處理？

【解決】 其實(shí)重復(fù)的情況有兩種：

1. 可能是表里已經(jīng)存在數(shù)字相同未核銷的取貨碼；
2. 另外一種情況就是別的事務(wù)在正在操作，正好有個(gè)分布式事務(wù)鎖住了一樣的數(shù)字碼（概率很低，但是是有可能的）。

這兩種情況的出現(xiàn)就需要我們進(jìn)行優(yōu)雅地重試了！大致思路如下偽代碼：

//step1根據(jù)分庫(kù)分表因子獲取庫(kù)表編號(hào)，userCode-用戶編號(hào)、tenantId-租戶編號(hào)
Stringsuffix=getCodeSuffix(userCode,tenantId);

//step2批量獲取6位隨機(jī)碼
for(inti=1;i<=5;i++){
//批量獲取隨機(jī)數(shù)。每次重試，取2的指數(shù)級(jí)量進(jìn)行過(guò)濾，相比暴力執(zhí)行for循環(huán)，這種方式能減少和DB的交互
ListtempCodes=getRandomCodes(2<//過(guò)濾掉分布式鎖
filterDistributeLock(tempCodes);
//過(guò)濾掉數(shù)據(jù)庫(kù)存在的隨機(jī)碼
filterExistsCodes(tempCodes);
returntempCodes;
}

//step3處理隨機(jī)碼，隨機(jī)碼入庫(kù)
for(Stringcode:codes){
//加鎖，判斷加鎖是否成功。推薦使用Redis分布式鎖
booleanhasLockd=isLocked(code);
try{
//執(zhí)行入庫(kù)
insert(object);
}finally{
//解鎖
}
}

//step4執(zhí)行后置二維碼圖片等邏輯

【注意】

1. 推薦使用指數(shù)級(jí)重試的方式（2 << i），逐次遞增random的數(shù)量，減少和DB的交互；
2. 建議數(shù)字碼生成完畢后加鎖并執(zhí)行INSERT，生成圖片地址等耗時(shí)嚴(yán)重的動(dòng)作可以后置UPDATE上去。

【問(wèn)題二】 項(xiàng)目中使用了分庫(kù)分表的組件（比如：ShardingSphere-JDBC），怎么動(dòng)態(tài)修改數(shù)據(jù)源？也就是同時(shí)支持分庫(kù)分表因子（比如：member_id、open_id等）以及根據(jù)取貨碼計(jì)算的庫(kù)表動(dòng)態(tài)查詢。

【解決】 我們以ShardingSphere-JDBC作為為案例來(lái)給出一些配置及偽代碼，具體可以參考：《強(qiáng)制路由::ShardingSphere》，其他開(kāi)源的分庫(kù)分表組件或者自研產(chǎn)品不做贅述，可以自己手動(dòng)寫個(gè)插件，別怕，即使再難，也要相信有光！

配置及偽代碼

//ShardingSphere-JDBC依賴的配置文件jdbc-sharding.yaml
...
shardingRule:
tables:
...
#取貨碼表
order_code:
actualDataNodes:DS00$->{0..3}.order_pick_up_0$->{0..3}
#配置庫(kù)的計(jì)算邏輯
databaseStrategy:
hint:
algorithmClassName:com.xxx.xxxxx.xxx.service.impl.DbHintShardingAlgorithm
#配偶之表的計(jì)算邏輯
tableStrategy:
hint:
algorithmClassName:com.xxx.xxxxx.xxx.service.impl.DbHintShardingAlgorithm
...

//java代碼
try(HintManagerhintManager=HintManager.getInstance()){
hintManager.addDatabaseShardingValue("order_code"/**取貨碼表*/,DbHintShardingAlgorithm.calDbShardingValue(tenantId,code));
hintManager.addTableShardingValue("order_code"/**取貨碼表*/,DbHintShardingAlgorithm.calTabShardingValue(tenantId,code));

Objectxxx=xxxMapper.selectOne(queryDTO);
}

【注意】

1. 這里介紹一種編程式的解決方案，好處是配置簡(jiǎn)單、比較靈活，缺點(diǎn)就是代碼稍微多一點(diǎn)。其實(shí)ShardingSphere還支持注解的方式，可以自己研究下；
2. 第一條說(shuō)了比較靈活，體現(xiàn)在自己實(shí)現(xiàn)的 “DbHintShardingAlgorithm.calDbShardingValue(tenantId, code)” 方法上，這個(gè)方法可以自己定義，所以我們的入?yún)⒖梢允峭ㄓ玫姆謳?kù)分表因子，也可以是自定義的取貨碼的“庫(kù)表位置”字段，非常靈活。

【問(wèn)題三】 如何做到更強(qiáng)的擴(kuò)展性，適用SaaS平臺(tái)以及不同的業(yè)務(wù)場(chǎng)景？

【解決】 細(xì)心的小伙伴應(yīng)該注意到了 "tenantId" 這個(gè)字段，這是個(gè)租戶的編碼，在實(shí)際編碼會(huì)進(jìn)行透?jìng)?。我們可以利用這個(gè)字段針對(duì)不同的租戶（或叫業(yè)務(wù)方）來(lái)做不同的配置，比如：取貨碼的長(zhǎng)度、取貨碼編排的方式、取貨碼映射庫(kù)表位置的策略等等做成可配，只要把主干邏輯進(jìn)一步抽象，并使用策略模式進(jìn)行個(gè)性化編碼。

四、總結(jié)

實(shí)現(xiàn)取貨碼邏輯的時(shí)候，發(fā)現(xiàn)網(wǎng)上券碼這塊的方案、技術(shù)文章比較少，當(dāng)時(shí)萌生了寫篇文章拋磚引玉做個(gè)分享的想法。事實(shí)上，我相信大多數(shù)公司可能或多或少也是這么做的，哪怕采取了別的方案也能殊途同歸。本篇文章整體只是介紹了一個(gè)思路，而這個(gè)思路類似一個(gè)簡(jiǎn)化版的訂單分庫(kù)分表，但這就是神奇所在，事實(shí)上我們還可以將一些常用的技術(shù)方案落地到不同的應(yīng)用場(chǎng)景，大膽地做一些嘗試，多走一些未曾設(shè)想過(guò)的道路！

審核編輯 ：李倩