業務ID 生成規則

在實際業務中，是否碰到過這種場景：

咱們須要一個單號，要在業務系統裏面保證惟一，保證增加？

在運營過程，須要知道業務單發生的時間，最好不用通過系統查找就知道發生的時間？

在排障過程當中，不用再次查找就知道，訂單的一些信息？

 

業務ID 常常須要生成以方便後續跟蹤使用。通常須要知足如下特性：

1. 惟一性

2. 可閱讀

3. 增加

4. 數字類型？

5. 其餘信息(payload)

 

因此，業務ID的生成，這裏涉及兩個問題：

1. ID 的規則，也就是ID 最終長什麼樣，知足什麼約束

2. ID 生成策略

 

好比，一個常見的訂單號生成規則可能以下：{yyyyMMddHHmm}[0-9][0-9]{4}

這個規則知足瞭如下約束：

1. 17位數字， 數據庫存儲能夠用BIGINT 存儲， 各系統接口可使用Long 類型交互

2. 能夠閱讀， 經過{yyyyMMddHHmm} 快速的知道訂單的建立時間

3. 能夠猜想類型， 如中間的[0-9],支持10種類型， 這個數據豐富信息，可不存。

4. 支持的最大併發在每分鐘10000，在系統確實有每分鐘10000個訂單，這個單號生成策略就夠了

 

固然，上述訂單號規則，只是一種實例，不過對大多數小系統足夠了。即使是這樣，上述規則，也有一些缺陷。

好比Long 範圍的限定狀況下， 使用了相似string 的 拼接技術，未能充分使用Long的範圍。

 

若是ID 規則，不用太多考慮可讀性的話， 能夠像設計序列化協議同樣，設計的更爲緊湊，以容納更多信息， 好比Long 有64bit，能夠按照bit 長度劃分紅若干段。

 

 

現實中，有不少系統爲了單號的可讀性，常常會超出Long的最大值，因此設計爲 NChar(128) 也比較常見。