訂單是整個電子商務的核心，整個電子商務的流程也是圍繞訂單展開的；本文與大家分享一下各大電子商務**訂單號的生成方式。
首先我們要先知道訂單號是什麼？
它是您在購物**購物後獲得的訂單號，記錄的是購物訂單資訊；在您需要與購物**進行訂單查詢等操作時，需要給購物**提供商家訂單號。
大部分的幾種常見下單途徑如下？
web**下單。
打**到呼叫中心（callcenter）下單。
手機wap下單。
訂單的一些規則
訂單命名規定
這個大家都明白，主要保證訂單號不重複。
訂單編號不能透露你公司的真實運營資訊，比如你的訂單就是流水號的話，那麼別人就可以從訂單號推測出你公司的整體運營概括了。所以訂單編碼必須是除了你們公司少部分人外，其他人基本看不懂的。可以參考京東和**的編碼規則。
因為大規模的隨機碼隨機生成，因為本身就沒有意義所以無所謂洩密了。但是事實上這種編碼規則在實現上會有很大問題的。隨機碼滿足第二點安全性要求，為了滿足唯一性，那就得在生成隨機碼的時候對比歷史資料是否有重複，如果你的訂單數量到達了十萬次，你每次生成訂單編碼時就得對比十萬條歷史資料。
這裡有同學可能會問：隨機碼就不能在編碼中使用了嗎？
小規模的隨機碼是可以使用的，比如2~3位，這種隨機碼一般都是和流水號等結合使用，主要作用是為了隱藏流水號的真實資料而進行使用的。
主要針對編碼中有時間的設定。
訂單號的作用就是便於查詢。一般正常使用場景應該是訂單出異狀或者退貨的時候，使用者將訂單號報給客服，由客服進行查詢。所以一般在10~15位為好。目前京東11位，**16位。
直接進入主題，我們生成訂單號有很多方案
方案一:業務號+年（年份後兩位）+月+日+訂單數。核心邏輯，新建一張訂單表維護每天的訂單新增數量，生成訂單時，從表中查詢到訂單數，組合上面的其他幾項行成新的訂單號碼。
方案二:新建一張全域性訂單表，存放乙個自增的id欄位，每次生成訂單號時候，在全域性訂單表中插入一條記錄，使用id作為新訂單的訂單號。
以上兩中方案都能解決在分庫分表的情況下保證訂單號的唯一性，但是每次生成訂單號的時候都需要去一張表中插入（更新）一條記錄。在高併發下會存在效能瓶頸問題。
方案三:業務編碼+時間戳+機器編號【前4位】+隨機4位數+毫秒數
電商網線如何設計訂單號
有意義的位數的訂單號日期 訂單 支付型別 業務標記 使用者id 自遞增數這樣就比較一目了然，也是很常見的 設計方案 可以反解的訂單號，本身一眼是看不出你訂單的意義可以通過反解訂單知道此訂單的情況，這不是和方案1一樣嗎？方案一會暴露系統的訂單設計意義，方案可能會涉及到加密等問題，為了資料安全考慮 無意...
電商平台訂單號生成策略
訂單是整個電子商務的核心。整個電子商務的流程也是圍繞訂單的狀態執行的。這篇部落格主要向大家介紹訂單號的生成方式。現在大型電商 大多都有好幾種下單途徑。比如 通過web 下單，通過打 到呼叫中心下單 callcenter 使用手機wap下單。如果只採用單資料庫來儲存訂單資訊的話，其隨著訂單量的增加，單...
訂單號的處理
自動編號會被人猜出來嫩 每天的下單量,每季度的下單量,每年的下單量.等於直接把 經營資料拱手他人.所以一般都是無法跟下單量直接掛鉤的單號 一 ecshop訂單號生成規則 function get order sn ecshop的訂單號是會重複，ecshop生成訂單號後會做判斷，如果訂單號重複則重新提...