訂單是整個電子商務的核心。整個電子商務的流程也是圍繞訂單的狀態執行的。這篇部落格主要向大家介紹訂單號的生成方式。
現在大型電商**大多都有好幾種下單途徑。比如：通過web**下單，通過打**到呼叫中心下單（callcenter)，使用手機wap下單。如果只採用單資料庫來儲存訂單資訊的話，其隨著訂單量的增加，單資料庫寫壓力必然增大，資料庫伺服器就會不堪重負，所以大都會根據業務採用分庫做法。如下：
目前幾個大型電子商務**是如何生成訂單號的呢。讓我們先看看訂單號的格式吧。
京東**訂單號格式：157444499；蘇寧易購訂單號格式：2000839647；凡客誠品訂單號格式：213052230059；銀泰網訂單號格式：10030522161715。
web****訂單呼叫生成訂單api後，儲存在web訂單庫。callcenter**呼叫生成訂單api後，儲存在callcente訂單庫。wap**訂單呼叫訂單生成api後，儲存在wap訂單庫。最後需要把web訂單庫，callcenter訂單庫，wap訂單庫等資料同步到後台訂單主庫中。後台訂單主庫是我們的核心庫，儲存所有訂單資料。那麼我們怎麼才能把不同庫中的訂單資料同步到後台主庫中，需要滿足什麼條件呢？電商**中訂單表大多都是以訂單號做表的主鍵，我們必須保證各個子訂單庫中儲存的訂單號不能重複。這樣才能保證可以安全的同步到後台主庫中。
我們先來分析一下凡客誠品和銀泰網的訂單號生成規則。初看一下，凡客誠品和銀泰網訂單號都含有0522，這是因為這2張訂單都是2023年5月22號下的訂單。我們總結一下，凡客的訂單規則：業務編碼+年的後2位+月+日+訂單數。銀泰網的訂單號規則：年的第三位數+業務編碼+年的後1位+月+日+訂單數。其實現方式應該是在資料庫中新建一張訂單量記錄表維護每天的訂單量。生成訂單時，根據當天的日期查詢這張表的訂單數量加1，然後組合業務編碼（比如業務編碼web=1，callcenter=2,wap=3）即為訂單號。生成訂單成功後在回寫資料庫（需記錄訂單量）。這種方式在高併發下會頻繁更新訂單量記錄表，很容易產生鎖表。
京東**和蘇寧易購的訂單號看不出規則。我們猜想應該是 有乙個全域性資料庫，這個資料庫中只有一張訂單表(order),表order只有乙個自增的字段id，這個自增的字段id就是訂單號。所有生成訂單的api會首先訪問全域性資料庫的order表獲得訂單號，然後再生成訂單。這樣就可以保證子庫訂單號不重複。其實現方式避免了頻繁的更新操作，只有insert操作，效能要好很多
訂單號生成
之前用uuid 因為太長改用16位因此在網上找到一下這種做法,年月日擷取 時間戳 在加隨機數 生成乙個訂單 獲取年份 var date j f c d e b h i a date gettime tostring var ordersn date new date getfullyear 2015...
電商網線如何設計訂單號
有意義的位數的訂單號日期 訂單 支付型別 業務標記 使用者id 自遞增數這樣就比較一目了然，也是很常見的 設計方案 可以反解的訂單號，本身一眼是看不出你訂單的意義可以通過反解訂單知道此訂單的情況，這不是和方案1一樣嗎？方案一會暴露系統的訂單設計意義，方案可能會涉及到加密等問題，為了資料安全考慮 無意...
電商中的訂單號如何實現
訂單是整個電子商務的核心，整個電子商務的流程也是圍繞訂單展開的 本文與大家分享一下各大電子商務 訂單號的生成方式。首先我們要先知道訂單號是什麼？它是您在購物 購物後獲得的訂單號，記錄的是購物訂單資訊 在您需要與購物 進行訂單查詢等操作時，需要給購物 提供商家訂單號。大部分的幾種常見下單途徑如下？we...