訂單號生成規則

前陣子，公司有個電子商務項目，須要生成訂單號。
當時的考慮很簡單，取系統時間加上隨機數，或者使用 uniqid() 方法。
咱們都知道，訂單號最基本的要求就是惟一，這個條件必須知足。仔細考慮下上述方法，在顧客購買量少的狀況下，訂單重複的可能性爲零，可是在購買高蜂期生成的訂單號重複是頗有可能發生的。因此上述方法不可靠，有待強化。
在網上找了一番，發現這位同窗的想法挺不錯的，redtamo，具體的請穩步過去看看，我做簡要概述，該方法用上了英文字母、年月日、Unix 時間戳和微秒數、隨機數，重複的可能性大大下降，仍是很不錯的。使用字母頗有表明性，一個字母對應一個年份，總共16位，很少也很多，呵呵。

<?php 
    $yCode = array('A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J');
    $orderSn = $yCode[intval(date('Y')) - 2011] . strtoupper(dechex(date('m'))) . date('d') . substr(time(), -5) . substr(microtime(), 2, 5) . sprintf('%02d', rand(0, 99));
?>

 訂單號規則:

訂單命名的幾種規則：
一、不重複。
這點我相信你們都懂，訂單的惟一性不用解釋。
二、安全性。
你的訂單編號不能透露你公司的真實運營信息，好比你的訂單就是流水號的話，那麼別人就能夠從訂單號推測出你公司的總體運營歸納了。因此訂單編碼必須是除了大家公司少部分人外，其餘人基本看不懂的。參考京東和淘寶的編碼規則，基本別人是搞不清是什麼意思的。
其實最好的防泄漏編碼規則就是在編碼中不要加入任何和公司運營的數據。
三、不能使用大規模隨機碼。
不少人分析訂單編碼規則的時候，第一個念頭確定是不重複惟一性，那麼第二個念頭可能就是安全性，那麼同時知足前二者的第三個念頭就是隨機碼了。由於大規模的隨機碼隨機生成，由於自己就沒有意義因此無所謂泄密了。可是事實上這種編碼規則在實現上會有很大問題的。
隨機碼知足第二點安全性要求，爲了知足第一點不重複特性，那就得在生成隨機碼的時候對比歷史數據是否有重複，若是你的訂單數量到達了十萬次，你每次生成訂單編碼時就得對比十萬條歷史數據，你可想而知會形成什麼巨大問題。
可是難道隨機碼就不能在編碼中使用了嗎？小規模的隨機碼是可使用的，好比2~3位，這種隨機碼通常都是和流水號等結合使用，主要做用是爲了隱藏流水號的真實數據而進行使用的。
PS:在這裏感謝 @馬馳@dad ni @bao xu（這個不知道爲什麼@不到）同窗的討論，馬馳同窗實際測試估算了生成隨機碼而且檢測重複所花費的時間在納秒級別。可是我仍是保持原來觀點，以爲這種生成規則存在方向性問題，可能會形成檢測時間過長的問題出現。
但願你們積極參與討論。
四、防止併發。
這條規則主要針對編碼中有時間的設定。
五、控制位數。
這點很好理解，訂單號的做用就是便於查詢。
通常正常使用場景應該是訂單出異狀或者退貨的時候，用戶將訂單號報給客服，由客服進行查詢。
因此通常在10~15位爲好。
京東10位，淘寶15位。
推薦的幾種編碼規則：
年月日時分秒+用戶ID(命名用戶ID時也要注意，不要用流水號。能夠採用區域ID+隨機碼+流水號+隨機碼方式)
一、惟一性：時間是單向的，確保惟一性。
二、安全性：確保用戶ID安全便可。
三、隨機碼不參與判斷，由於以前數據已確保無重複。
四、在同1秒鐘，同一用戶是不會產生2個訂單編碼的，因此能夠防併發。
五、位數可能會在20位以內，位數比較多。
年月日時分秒微秒+隨機碼(2)+流水號+隨機碼(3)
一、惟一性：時間是單向的，確保惟一性。
二、安全性：確保流水號不會識別出便可。
三、隨機碼的位數和先後都是保密的，因此若是不清楚這一點的話，是很難判斷出流水號的位數的。由於同時產生的訂單數量不少，編碼不具有線性對比功能。就算知道了流水號，能夠在初始化時進行賦值。
四、在同1秒鐘，同一用戶是不會產生2個訂單編碼的，因此能夠防併發。
五、位數可能會在20位以內，位數比較多。
（以上來自知乎@benben）
==============================================
訂單號常見的幾種方式：
1.利用數據庫主鍵值產生一個自增加的訂單號（訂單號即數據表的主鍵）
2.日期+自增加數字的訂單號（好比：2012040110235662）
3.產生隨機的訂單號(65865325365966)
4.字母+數字字符串式，字母有包含特別意義，C02356652
訂單號設計原則： 按需設計
　　用來檢索訂單詳細信息的惟一特徵碼，能夠利用訂單號檢索到下單日期、產品類別、顏色、尺碼（或款式）、倉位等信息，訂單號包含過多的信息有點「多此一舉」的意味！只要按需設計便可！
訂單號設計用戶體驗規則：
1.訂單號無重複性；
2.若是方便客服的話，最好是「日期+自增數」樣式的訂單號，客服一看便知道訂單是否在退貨保障期限內容；
3.訂單號長度儘可能保持短（10位之內），方便用戶，尤爲電話投訴時，長的號碼報錯概率高，影響客服效率；
4.訂單號儘可能保持數字型(純整數)，在數據庫訂單索引查詢中，長整數字型的數據索引與檢索效率，遠遠高於文本型，所以儘可能避免「字母+數字字符串式」！