互聯網快速發(fā)展的今天，各類商城平臺不計其數，商城及支付平臺都有訂單系統(tǒng)，訂單系統(tǒng)里有一個關鍵元素就是訂單號，訂單號要具備全局唯一性。另外一方面，在分布式系統(tǒng)中也需要各種各樣的ID，同樣要求全局唯一性。

訂單號生成方案

在一般項目中，我們要生成訂單號可選的方案很多，比如說：

1、數據庫自增長ID

• 優(yōu)點：借助數據庫實現，無需代碼實現；
  

• 缺點：不能做水平分表，因為ID可能會重復；高并發(fā)場景下生成效率低速度慢；

2、時間戳 + 隨機數

• 優(yōu)點：實現起來簡單
  

• 缺點：即使在相同的時間戳下隨機數依舊存在重復的可能

3、會員ID + 時間戳

• 優(yōu)點：同一時間內，同個用戶不會存在兩個訂單號
  

• 缺點：會員ID泄露，存在一定風險

4、GUID、UUID

• 優(yōu)點：簡單
  

• 缺點：生成的訂單號不友好、索引效率低下

高并發(fā)場景下生成的訂單號存在重復的可能

所謂的高并發(fā)是指在較短時間段內服務器需要并行處理的請求數很多。在高并發(fā)場景下，同一秒可能會生成很多訂單號，這樣一來訂單號就存在重復的可能性。

另外一方面，如果是多線程或者分布式環(huán)境下同一秒生成的重復訂單可能性更大！

高并發(fā)、分布式環(huán)境下生成訂單號的方案

1、利用Redis原子遞增來實現（推薦）

因為Redis本身就是單線程的，再借助其原子操作INCR、INCRBY完全可以生成全局唯一的ID，而且速度快。

2、時間戳 + 多個隨機數 + 樂觀鎖

3、GUID轉換為數字

以上就是我的觀點，對于這個問題大家是怎么看待的呢？歡迎在下方評論區(qū)交流 ~ 我是科技領域創(chuàng)作者，十年互聯網從業(yè)經驗，歡迎關注我了解更多科技知識！

高并發(fā)下如何生成唯一訂單號（唯一主鍵），有幾個方案和大家分享一下。

利用數據庫生成

先說最笨的方法，利用數據庫的自增長序列生成，數據庫內唯一；數據庫生成唯一主鍵，別的系統(tǒng)過來�。�

• 優(yōu)點：理解起來最容易，用起來也最容易。

• 缺點：也非常明顯了，每種數據庫的實現不同，如果數據庫需要遷移的話比較麻煩；最大的問題是性能問題，因為題目中提到了【高并發(fā)下】，所以使用這個方法估計會很難滿足性能需求。

利用Redis/MongoDB/zookeeper生成

Redis的單線程的，利用incr和increby；MongoDB的ObjectId；ZK通過znode數據版本；都可以生成全局的唯一標識碼。

• 優(yōu)點：性能高于數據庫；可以使用集群部署。

• 缺點：需要引入對應的組件，增加系統(tǒng)的復雜度。

UUID

這個是分布式架構中，生成唯一標識碼最常用的算法。UUID有基于MAC地址的，加上時間和時鐘序列的，也有基于偽隨機數的，基于加密哈希的。

• 優(yōu)點：本地生成，不需要第三方組件，生成比較簡單，性能好。

• 缺點：長度長，不利于存儲，并且沒有排序，是個字符串，不利于查詢。解決無序問題，可參考Comb算法（combined guid/timestamp）。

Snowflake

Twitter開源，基于zk，41位時間戳（毫秒數）+10位機器的ID+12位毫秒內的流水號+1位符號位（永遠是0）。

• 優(yōu)點：性能不錯，單機內遞增。

• 缺點：依賴zk；依賴于機器時鐘，分布式環(huán)境內可能會不是全局遞增。

UidGenerator

百度開源，基于snowflake算法。

Leaf

美團開源。

• 優(yōu)點：能保證全局唯一性、高可用、趨勢遞增（不太安全，比如泄露公司訂單數量）、單調遞增等。

• 缺點：依然會依賴第三方組件，zk或數據庫。

我將持續(xù)分享Java開發(fā)、架構設計、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關注。

互聯網架構

分布式/集群環(huán)境ID生成要求

1. 全局唯一
2. 高并發(fā)支持
3. 高可用
4. 趨勢遞增
5. 信息安全
6. 可讀性

ID 生成策略

1、UUID

1. 通用唯一識別碼
2. 組成： 當前日期 + 時間 + 時鐘序列 + 機器識別碼(MAC地址或其他)
3. 在分布式系統(tǒng)中，所有元素都不需要通過中央控制端來 判斷數據的唯一性

2、數據庫自增

• 關系型數據庫都實現數據庫自增ID；Mysql通過AUTO_INCREMENT實現、Oracle通過Sequence序列實現。
• 在數據集群環(huán)境下，不同數據庫節(jié)點可設置不同起步值、相同步長來實現集群下生成全局唯一、遞增ID
• SET GLOBAL auto_increment_increment = 3
• SET GLOBAL auto_increment_offset = 1;

3、Snowflake

• 41位時間戳+10位機器ID +12位序列號(自增),轉換為長度為18的長整型
• Twitter為滿足每秒上萬條消息的創(chuàng)建，每條消息都必須分配全局唯一ID，這些ID需要趨勢遞增，方便客戶端排序。

4、Redis

• Redis 實現自增ID
• Redis實現了incr(key) API用于將key 的值遞增1，并返回結果，如果key不存在，則創(chuàng)建并賦值為0，然后再執(zhí)行incr操作。

幾種策略總結

時間戳+用戶ID+隨機數

UUID

這種方式比較方便，有現成可用的JAR包，但是也有缺點：ID可讀性不好，而且會造成索引樹頻繁頁分裂，影響數據庫性能和空間使用

數據庫序列表

維護一張序列表�？紤]到性能問題，不必每次生成ID都去操作數據庫，可以設置一定的步長比如1000，每次從表中拿1000個序列號，從每臺服務器內存中線性去取

Redis

維護一個序列號鍵值對，利用Redis自增的原子性，生成序列號

Snowflake

同一毫秒可以產生ID數量4194304個，優(yōu)點是完全內存操作性能好，缺點是依賴于系統(tǒng)時鐘一致性。如果某臺機器的系統(tǒng)時鐘回撥，有可能造成ID沖突，或者ID亂序

總結

最重要的還是根據項目的場景，尤其是并發(fā)量，選擇最合適的方法

敬請關注

請點擊關注按鈕【IT徐胖子】會持續(xù)為大家奉獻互聯網和技術干貨內容，感謝支持

由于是高并發(fā)情況，所以不建議使用數據庫自增ID，可以參考如下方案：

1、redis自增id

2、UUID

3、時間戳+隨機數

4、Twitter的snowflake算法

5、利用zookeeper生成唯一id，性能不如redis

6、MongoDB的ObjectId，和snowflake算法類似

雪花算法足夠了。我這邊兩個業(yè)務線都是用的雪花算法 完全能保證唯一。