vivo官網商城開發團隊 - Zhou Longjian

一、背景

隨著O2O線上線下業務的不斷擴展，電商平臺也在逐步完善交易側相關的產品功能，在最近的需求版本中，業務方為進一步提升用戶的使用體驗，規劃了取貨碼生成及訂單核銷相關邏輯，目的是讓線上的用戶在付完款之后能夠到店取歡訓者安排導購派送，

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

取貨碼長度相對較短，比起動輒十幾二十位訂單號，幾位的數字碼更方便記憶和輸入；
除了數字取貨碼，還提供二維碼，方便終端進行掃描并核銷，

取貨碼使用起很簡單，然而像“冰山”一樣，隱藏在簡單外表下面卻需要嚴謹的設計和細致的邏輯，可以說麻雀雖小五臟俱全，本文介紹的設計也比較有趣，而且按此思路可以實作市面上大多數核銷類券碼的生成，同時也能滿足業務的SaaS化，算是一個相對通用的能力，在此把整個設計分享給大家，

（圖片來源：pixabay.com）

二、簡單系統的單表業務

如果業務的體量不大，店鋪流量比較小，未形成平臺的規模，比如給個體經營者使用的系統，那么取貨碼或券碼的實作就比較簡單，跟訂單共享一張大橫表或者使用擴展表跟訂單進行關聯就行了，這個階段也無需做過度設計，

表的設計如下圖：

不過需要注意的是一般訂單號都是比較長的，通常都在十幾二十位（當然也有比較短的訂單號，如果訂單號比較短，取貨碼也可采用訂單號）我們假設訂單號18位，取貨碼8位，即訂單號的取值范圍遠大于取貨碼，那么在訂單號的生命周期內，取貨碼是有很大幾率存在重復的，解決起來相對簡單，我們只需要保證在任意條件下，未核銷狀態的數字碼不重復即可，也即已核銷的數字碼可以回收利用，

那么取貨碼的生成邏輯就很清晰了，下面用偽代碼模擬真實的實作邏輯：

偽代碼實作

for (;;) {
   step1 獲取隨機碼：String code = this.getRandomCode();
   step2 執行SQL：SELECT COUNT(1) FROM order_main WHERE code = ${code} AND write_off_status = 0;
   step3 判斷是否可以插入：if ( count > 0) { continue; }
   step4 執行資料寫入：UPDATE order_main SET code = ${code}, qr_code = ${qrCode}, write_off_status = 0 WHERE order_no = ${orderNo}
}

*注意：這里step2和step4不是原子操作，存在并發問題，實際應用中最好使用分布式鎖，把操作鎖住，

三、復雜平臺的分庫分表業務

通過簡單的單表設計，我們能管窺一斑，了解取貨碼大致的實作邏輯，不過我們在把簡單方案往大型專案上進行落地的時候，就需要考慮很多方面，設計也需要更精巧，SaaS化的電商平臺會比簡單的單表業務復雜很多，重點體現在：

SaaS 產品涉及的店鋪很多且訂單量大，需要設計大容量存盤，所以訂單表基本使用分庫分表，顯然作為訂單附屬的取貨碼表也得使用相同的策略；
B端和C端用戶的體驗非常重要，服務端介面的設計需要充分考慮魯棒性，完善最基本的重試及容錯能力；
不同業務方對于取貨碼的要求可能不太一樣，取貨碼的設計需要具有通用性以及個性化的配置屬性，

3.1 詳細設計

取貨碼表的設計推薦使用和訂單一致的分庫分表策略，好處是：

和訂單一樣，支撐海量訂單行的存盤；
方便利用同樣的分庫分表因子進行查詢（例如：open_id、member_id），

在考慮落地實作上，我們遇到了第一個討論的點，那就是取貨碼是做到“門店唯一”還是“全域唯一”？

3.2 門店唯一方案

剛開始考慮使用類似飯館取餐碼類似的邏輯，保證取貨碼在各自門店保持唯一就行了，類似如下圖互動，圖中用戶A和用戶B持有相同的取貨碼，用戶A、B分別去他們對應的店鋪完成核銷，整個交易程序就結束了，但是這得保證用戶A和B能正確地在各自訂單歸屬的店鋪完成核銷，顯然這個方案是帶有風險的！

下圖所示的這種情況下，用戶A、B也能正常核銷，不過串單了，原本屬于用戶A的訂單被用戶B核銷了，這種問題出現的本質原因在于純粹的數字碼無法帶有用戶的標識，雖然可以在核銷前做人為的核驗身份來避免，但依然屬于高風險的系統設計，所以門店唯一方案不可取！

3.3 全域唯一方案

全域唯一方案風險小，但實作難度稍高一點，核心問題在于如何判定隨機生成的取貨碼是全域唯一的，當然如果系統本身依賴ES這類存盤介質，可以在插入前先查詢ES，不過查詢和寫入ES對于實時性介面來說稍微有點重，沒有直接查庫表來得直接，假設某業務方分成了4個庫4張表，總計16表，取貨碼的長度確定為8位，那如何在多庫多表的Mysql中查詢并保證全域唯一呢？遍歷表的方式肯定不可取！

為解決上述的疑問，我們在設計的時候可以在取貨碼的編排上做點文章，如下步驟做具體詳解：

步驟①：可以將8位的取貨碼分成兩個區域，“隨機碼區域”+“庫表位置”，下圖示例：

步驟②：隨機碼區域暫不介紹，我們來看下2位庫表如何映射到4庫4表組成的16張表中，

這里也有兩套方案：

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

【方案二】將4庫4表二維結構轉成一維，以0為初始值進行遞增，(0庫, 0表) → 00, (0庫, 1表) → 01... , (3庫, 3表) → 15，好處是容量變大了，最大支持99張表，不受庫或表單一條件的限制，缺點就是映射邏輯寫起來麻煩點，不過這不是問題，

取貨碼經過簡單編排，我們完成了取貨碼的到庫表的映射邏輯，解決了取貨碼存取的問題，其實仔細想想，關于全域唯一的問題其實也解決掉了，我們只要保證前6位隨機碼在單表里保證唯一即可，理論上支持單表在未核銷狀態下范圍為：000000 ~ 999999條記錄，容量是足夠的，關鍵我們把多庫多表的查詢就簡化成了只跑一個SQL，效率大大提升，

3.4 方案落地遇到的問題

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

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

【解決】其實重復的情況有兩種：

可能是表里已經存在數字相同未核銷的取貨碼；
另外一種情況就是別的事務在正在操作，正好有個分布式事務鎖住了一樣的數字碼（概率很低，但是是有可能的），

這兩種情況的出現就需要我們進行優雅地重試了！大致思路如下偽代碼：

// step1 根據分庫分表因子獲取庫表編號，userCode-用戶編號、tenantId-租戶編號
String suffix = getCodeSuffix(userCode, tenantId);
 
// step2 批量獲取6位隨機碼
for (int i=1; i<=5; i++) {
   // 批量獲取亂數，每次重試，取2的指數級量進行過濾，相比暴力執行for回圈，這種方式能減少和DB的互動
   List<String> tempCodes = getRandomCodes(2 << i);
   // 過濾掉分布式鎖
   filterDistributeLock(tempCodes);
   // 過濾掉資料庫存在的隨機碼
   filterExistsCodes(tempCodes);
   return tempCodes;
}
 
// step3 處理隨機碼，隨機碼入庫
for (String code : codes) {
   // 加鎖，判斷加鎖是否成功，推薦使用Redis分布式鎖
   boolean hasLockd = isLocked(code);
   try {
         // 執行入庫
         insert(object);
   } finally {
      // 解鎖
   }
}
 
// step4 執行后置二維碼圖片等邏輯

【注意】

推薦使用指數級重試的方式（2 << i），逐次遞增random的數量，減少和DB的互動；
建議數字碼生成完畢后加鎖并執行INSERT，生成圖片地址等耗時嚴重的動作可以后置UPDATE上去，

【問題二】專案中使用了分庫分表的組件（比如：ShardingSphere-JDBC），怎么動態修改資料源？也就是同時支持分庫分表因子（比如：member_id、open_id等）以及根據取貨碼計算的庫表動態查詢，

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

配置及偽代碼

// ShardingSphere-JDBC依賴的組態檔jdbc-sharding.yaml
...
shardingRule:
  tables:
    ...
    # 取貨碼表
    order_code:
      actualDataNodes: DS00$->{0..3}.order_pick_up_0$->{0..3}
      # 配置庫的計算邏輯
      databaseStrategy:
        hint:
          algorithmClassName: com.xxx.xxxxx.xxx.service.impl.DbHintShardingAlgorithm
      # 配偶之表的計算邏輯
      tableStrategy:
        hint:
          algorithmClassName: com.xxx.xxxxx.xxx.service.impl.DbHintShardingAlgorithm
    ...
 
// java代碼
try (HintManager hintManager = HintManager.getInstance()) {
    hintManager.addDatabaseShardingValue("order_code"/** 取貨碼表 */, DbHintShardingAlgorithm.calDbShardingValue(tenantId, code));
    hintManager.addTableShardingValue("order_code"/** 取貨碼表 */, DbHintShardingAlgorithm.calTabShardingValue(tenantId, code));
     
    Object xxx = xxxMapper.selectOne(queryDTO);
}

【注意】

這里介紹一種編程式的解決方案，好處是配置簡單、比較靈活，缺點就是代碼稍微多一點，其實ShardingSphere還支持注解的方式，可以自己研究下；
第一條說了比較靈活，體現在自己實作的 “DbHintShardingAlgorithm.calDbShardingValue(tenantId, code)” 方法上，這個方法可以自己定義，所以我們的入參可以是通用的分庫分表因子，也可以是自定義的取貨碼的“庫表位置”欄位，非常靈活，

【問題三】如何做到更強的擴展性，適用SaaS平臺以及不同的業務場景？

【解決】細心的小伙伴應該注意到了 "tenantId" 這個欄位，這是個租戶的編碼，在實際編碼會進行透傳，我們可以利用這個欄位針對不同的租戶（或叫業務方）來做不同的配置，比如：取貨碼的長度、取貨碼編排的方式、取貨碼映射庫表位置的策略等等做成可配，只要把主干邏輯進一步抽象，并使用策略模式進行個性化編碼，

四、總結

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

主題系列文章：

vivo全球商城全球化演進之路—多語言解決方案
vivo 全球商城：商品系統架構設計與實踐
vivo全球商城-營銷價格監控方案的探索
vivo 全球商城：優惠券系統架構設計與實踐
vivo 全球商城：訂單中心架構設計與實踐
vivo 全球商城：從 0 到 1 代銷業務的融合之路
vivo 全球商城：架構演進之路

分享 vivo 互聯網技術干貨與沙龍活動，推薦最新行業動態與熱門會議，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/507238.html

標籤：架構設計

上一篇：i18next-反應-Firefox回傳“de”-Chrome回傳“de-DE”

下一篇：設計模式之（11）——享元模式

vivo 全球商城：電商平臺通用取貨碼設計