在php中關於生成訂單號的解決方案，值得借鑑。

前期開發的一個交易系統，原本使用的是uniqid()函式生成的。
uniqid()是根據系統時間經過一定演算法得到的一個結果，關於uniqid()的詳情手冊上很清楚。
當時的生產方式是：
$order_sn = str_replace('.', '', uniqid('', true));

這種方式理論上說會重複，但是在實際應用中我相信這種重複可以認為是不可能事件。但是，如果這件事情到此就結束的話我也就不會再寫這篇文章。這幾天做支付接入，國內某大型網路支付機構只支援傳遞最多16位的訂單號，無奈我只得調整訂單號的生產規則。
其實關於生成訂單號的方式非常多，大致有以下幾個引數被用到：
1、自增欄位，2、系統時間，3、隨機數，4、流水號。

一、資料庫自增欄位
二、簡單的使用系統時間
三、系統時間加隨機數
四、系統時間加流水號

先說說mysql資料庫自增欄位，這種方式是最簡單有效的方式，但同時也存在很大的弊端：
1、以mysql為例的int型別最多儲存10位的數字，如果使用bigint則在使用php的mysql_insert_id()取上次插入id時會出現錯誤，當然這個錯誤是可以採用某些方法避免的。

2、很多時候業務邏輯需要在資料未插入系統之前就獲得訂單號以進行一系列的處理，這樣就容易出錯。
比如當併發較高的時候系統獲取到下一次插入的id應該是10000，可是當真正insert的時候發現10000已經被其他插入行使用。

3、很容易透露出系統的銷量，從商業層面說這種方式不太合適。

4、表現不夠直觀，不能通過訂單號簡表達訂單資訊

簡單的使用系統時間也可以有多種方式比如直接使用time()生成10位數字,這種方式基本避免了資料庫自增欄位的大部分弊端，但同時也產生的一些新的問題，比如：併發量稍高(峰值每秒一次以上,相信這是個很小的值)就會產生相同訂單號，而這是業務邏輯所不允許的。為了解決重複訂單問題而使用隨機數或者流水號。

先說隨機數，這東西就跟看上去的字面意思一樣，總顯得不那麼可靠，我認為儘量不使用它參與唯一標識。
再說流水號，既然叫流水號，它的性質其實和自增欄位一樣，不同的是或許每天或者每月流水號又會重新計數。總得有個地方來儲存下一個（或者當前使用過的最大）流水號的值，如果存在檔案中那就需要考慮這個檔案的讀寫鎖的問題，就這個問題估計足夠寫書了，在此不予討論。如果以自增方式存在db中，那麼我們在程式生成訂單號之前需要多訪問（至少）一次db，這也就降低了程式效能，要知道資料庫訪問對程式的效能影響是非常明顯的。

相關連結：php 自動生成訂單編號二種方法

解決思路(php)，當然同時別忘了大前提是：限制長度16位
第一步：

$order_sn = date('ymdhis').substr(microtime(),2,4);

其實這種方式基本已經滿足需求了，無需訪問db無隨機數參與。但是如果兩次請求在相同的十萬分之一秒內產生，那麼相同訂單就產生了，看能否有辦法繼續提高。

date(‘his’)所表達的結果其實就是000000到235959，而且其中很多數字不會被用到比如126998。一天86400秒，如果從一天的0:0:0算起直到23:59:59使用00000-86400就可以完全表示，這樣下來我們就完全可以把date(‘his’)換成五位數字。既然time()函式就是按秒計數，那咱就取time()結果的後五位，同一天之內後五位不會重複出現，比如今天0:0:0後五位是98765，那麼到今天23:59:59後五位就應該是98765+86400去掉最高位，相信這個應該是很好理解的。

這就產生了第二步的結果：
$order_sn = date('ymd').substr(time(),-5).substr(microtime(),2,5);

這樣一來也導致無法直觀的表達出訂單生成的時分秒，但我認為(或者說從業務角度理解)這個屬於可接受範圍。同時這樣處理出現重複訂單的概率就降低到了第一步的1/10，我以為這應該不算一個小數字。還不滿意？ok，那繼續！

想要繼續降低重複可能性那就繼續提高時間精度，但是我們的長度限制只有16位，看來只有減少部分不長變動的字元。

date(‘ymd’)產生6位字元，而前兩位在一年之內都不會變化，第三到第四位也就是01-12。
前兩位我們可以使用a-z的字母來表示，系統開始執行的那一年用a，第二年用b，第三年用c……類推，我相信我寫的這程式執行不了10年。第三第四位完全可以使用一位16進位制數表示，這樣咱就又節約了兩位字元，這就可以在末尾加上00-99的隨機數。

現在看第三步的結果
 

（ www.）理論上說出現重複訂單號的概率又降到了第二步的1/100。
做個簡單測試，寫個php檔案，連續10次echo出這三步結果得到的$order_sn,中間無任何多餘程式。
第一種方案基本得到10個相同的結果。
第二種方案基本得到10個不同的結果，主要是後兩位不同，一般末位差一。
第三種方案得到10個不同結果末四位不同
當然這個測試不具備多少說服力

優點：
1、不用操作資料庫，效能較高。
2、較為直觀，不難看出訂單產生的大致時間

3、訂單號重複的概率極小，只有程式在百萬分之一秒內同時處理一個以上的生成訂單號請求，而且同時生成的0-99的隨機數也一樣才會出現重複的訂單號。

http://www.169it.com/tech-php/article-2953455988.html