編輯導語：訂單號、支付流水號、售后訂單號、快遞取貨號、電子券核銷碼等，這些都是我們日常在生活中進行會遇見和使用的一些單號，那么為什么有些單號那么長，有些只有幾位數？有些單號一看就知道年月日的信息，有些卻看不出任何意義？為什么我淘寶訂單的后幾位數都是一樣的？今天就來帶大家看一下訂單號的是怎樣生成的。
一、訂單編號作為唯一標識碼在業務中的應用場景
單號在實際的業務過程中是做為一個訂單的唯一標識碼的存在，提供訂單號就很方便業務人員快速定位訂單信息，給予用戶幫助。
1. 用戶訂單遇到問題，需要找客服進行協助
我們日常在電商平臺上面購買商品的時候，很多時候需要去向平臺客服反饋在訂單過程中遇到的問題，一般這個時候平臺客戶都是要求用戶填寫訂單編號的，這樣客服可以快遞鎖定訂單信息，給用戶信息問題的解答和處理。
2. 對訂單進行操作，如線下收款，訂單核銷
我們在第三方平臺上購買了某一個店鋪的線下優惠券的時候，工作人員需要對我們提供的優惠券進行核銷，核銷的依據一般來說就是訂單編號。
而在某些場景涉及到的線下收款，也會根據訂單號來進行訂單的確認和收款，不過日常在業務過程中將一般都將訂單號生成二維碼，再由工作人員掃碼進行操作，因此用戶在線下對于訂單號的感知并不是很強烈。
3. 內部進行訂單的處理或者跟進
從技術的層面去講，很多時候搜索訂單相關信息的時候都是以訂單ID作為唯一標識符，這是由于訂單號的生成規則的唯一性決定的（后面講訂單號生成規則會講到）。
由此公司內部在進行業務操作處理時候，比如對通知倉庫按單發貨，內部交流某個訂單信息時候，也會直接根據訂單號來進行信息傳達。
二、編號規則的設計原則
訂單號的在業務中的使用一般都是基于唯一性的需求，因此在訂單號的設計上需要遵循幾個原則：
1. 不得重復
由于我們在業務中對于訂單編號的要求是唯一的，所以訂單編號生成的時候一定要遵循不可重復這一特性，而實際在底層生成訂單編號的時候由于業務流水很大，處于一個高并發的狀態，并且訂單號的生成規則一般是固定的，所以可能會造成在同一時間多個線程讀取的生成參數相同，從而造成生成的訂單號相同（當然這是開發人員應該注意的問題）。
其次就是業務的長時間積累可能導致新生成的訂單號會與過去很久的訂單號產生重復，所以在設計訂單號的時候一定要充分考慮到不可重復性的原則（后面講到訂單號設計中的變量部分會詳細講到）。
2. 安全性
編號不能透露公司的運營情況，比如日銷、公司流水號等信息，以及商業信息和用戶手機號，身份證等隱私信息。并且不能有明顯的整體規律（可以有局部規律），任意修改一個字符就能查詢到另一個訂單信息，這也是不允許的。
類比于我們高考時候的考生編號的生成規則，一定不能是連號的，否則只需要根據順序往下查詢就能搜索到別的考生的成績，這是絕對不可允許。
3. 具備一定的可讀性
位數要便于操作，因此要求訂單號的位數適中，且局部有規律。這樣可以方便在訂單異常，或者退貨時客服查詢。
過長的訂單號或易讀性差的訂單號會導致客服輸入困難且易錯率較高，影響用戶體驗的售后體驗。因此在實際的業務場景中，訂單號的設計通常都會適當攜帶一些允許公開的對使用場景有幫助的信息，如時間，星期，類型等等，這個主要根據所涉及的編號對應的使用場景來。
而且像時間、星期這些自增長的屬于作為訂單號的設計的一部分元素，有助于解決業務累積而導致的訂單號重復的問題。
三、編號設計中的常用變量
在遵循涉及原則的基礎上，我們常會使用一些變量來進行編號的設計，這也是為了滿足訂單編號的局部可讀性帶來的業務優勢，通常會有以下幾類：
1. 時間
如20220525105959這種類型的年月日時分秒，編號中使用這個變量就把重復的可能性降低到一秒內的不重復。
常用的時間變量還有很多變種類型，如取年份的后2位數、如20220525只保留到天。通常在快遞取件碼的設計中會使用月、日、周等+其他元素的設計，這是為了方便取件碼可以快速重復使用，因為快遞取件碼通常有效期不會超過一個月就會原路退貨然后被銷毀。
2. 時間戳
時間戳是一個10位數的數字，代表的是當前時間距離1970年1月1日UTC/GMT的午夜）開始所經過的秒數。也是經常用來代表時間的一種方式，時間戳也可以精確到毫秒，形成一個13位數的數字。
3. 類型
如訂單類型、售后類型、商品類型、支付類型等等，不同類型的可以使用不同參數進行。通常支付類型的應用場景是，線上支付和線下支付共用一套業務后臺，所以為了方便區分會加入支付類型這個參數用于區分線上線下。
類比還有店鋪代碼、支付的機器代碼、操作員代碼等等。
4. 用戶ID
對一些涉及到用戶的編號規則時候，可以使用到用戶ID作為變量來進行設計，如淘寶的訂單號中最后幾位數就使用了用戶ID，不過要注意不能使用完整的用戶ID，需要進行一些規則的設計再使用。
5. 商家ID
對電商系統中，可以把商家ID脫敏后也作為一個變量設計到編號規則中。
6. 手機號
使用用戶的手機號中的某些位數作為編號中的一個變量；使用類似于手機號部分號碼這種重復度較高的屬性設計訂單編號的時候，切記不能只有一個變量，否則很容易出現訂單編號重復。
7. 平臺形態
如果是多終端多平臺的系統，那么可以考慮在編號中把平臺作為一個變量考慮進去。如小程序平臺用01,安卓app使用01，PC版本使用03,第三方平臺04類型這樣的規則。
8. 其他業務屬性
可以根據業務場景，把一些業務屬性的信息也作為變量設計進去。
9. 隨機數
隨機數就是系統根據程序在一定規則內隨機生成的字符，可以為數字也可以是字符串，一般可以用來降低重復；隨機數在訂單生成中的使用頻率非常高，常常是前面幾位都是一些顯式的規律性數字，比如訂單生成的時分秒，然后最后加上四位隨機數從而組成訂單號。所以讀者在設計訂單編號的時候，如果不知道如何加密，就可以簡單的插入幾位隨機數即可。
10. 序列位
代表順序的數字，如10,11,12這樣的。
11. 驗證位
一般放在最后，根據前面的多位字符按照一定的規則計算最后得到的一個數字，一般為1位，主要目的是提高編號的安全性；身份證的最后一位就是校驗位，其計算原理也是通過前面幾位數字加密算法算出來的，感興趣的讀者可以去了解一下身份證的生成規則。
12. 地區信息
對有區域性質的編號規則里面可以考慮把區域作為變量考慮進去，如某地區分店、某地區線下的售貨機等。
13. 數據庫數據的自增ID
每條數據錄入系統時候，一般情況都有一個唯一的ID，這個ID也可以作為編號的一種變量進行使用。
四、編號實踐方案分享
1. UUID
通?唯?識別碼，是?種軟件建構的標準，亦為開放軟件基?會組織在分布式計算環境領域的?部分。其?的是讓分布式系統中的所有元素，都能有唯?的辨識信息，?不需要通過中央控制端來做辨識信息的指定。
- 1~8位采?系統時間，在系統時間上精確到毫秒級保證時間上的惟?性。
- 9~16位采?底層的IP地址，在服務器集群中的惟?性。
- 17~24位采?當前對象的HashCode值，在?個內部對象上的惟?性。
- 25~32位采?調??法的?個隨機數，在?個對象內的毫秒級的惟?性。
通過以上4種策略可以保證惟?性。在系統中需要?到隨機數的地?都可以考慮采?UUID算法。但是呢直接使用這個作為單號。雖然具有唯一性，安全性，但是卻沒有任何的可讀性而言。因此在這種情況下，UUID只是能作為系統中間的標識碼，可以在業務中數據流轉的時候配合訂單號使用，絕不可直接給予客戶和業務人員使用。
2. 時間戳+隨機數
對于一些編號需求不是很大的場景，如果可讀性也沒什么場景的要求，可以簡單的使用時間戳和隨機數進行拼接作為編號規則使用；如時間戳1635302466+隨機數2313，則編號為16353024662313。
3. 淘寶訂單號的生成規則
一共19位數，前面13位數為根據時間戳和內部定義序列，后面6位數為跟購買者ID相關的用戶位。
4. 有贊商家端的訂單號
日期+時分秒+隨機數。
5. 時間+時間戳+用戶+序列位
時間：取時間的年份后2位+月份+日期形成如211027。
時間戳：取時間戳的后6位數
用戶：取用戶ID的后5位數，序列位2位數隨機。
6. 綜合各種變量
下單渠道1位+支付渠道1位+業務類型1位+時間信息4位+下單時間的Unix時間戳后8位（加上隨機碼隨機后的數字）+用戶userid后4位共19位并不一定需要把19位全加上。
7. 預先生成
系統預先生成不重復的編號，業務系統要使用時候按順序取數即可。這種編號一般系統擁有一套成熟的加密規則，不屬于常規的訂單生成規則，一般用于加密程度較高的業務。
聲明：本文由網站用戶香香發表，超夢電商平臺僅提供信息存儲服務，版權歸原作者所有。若發現本站文章存在版權問題，如發現文章、圖片等侵權行為，請聯系我們刪除。
