專案地址

常見的UID優缺點

資料庫自增ID

簡單可靠，有序，可讀性好，效能也不錯。缺點是要鎖表，效能會有瓶頸，分庫特別是已分庫的情況再擴容時會比較麻煩。

UUID

全球唯一，效能好，缺點是太長了，儲存空間大，索引效能不好，長度太長使用起來也不方便。另外部分UUID演算法生成的不是趨勢遞增的。

Redis生成

效能好，有序，可讀性好。缺點是為了防單點故障，需要引入Redis叢集，增加了額外編碼和配置的工作量。

Snowflake生成ID

twitter開發的一套全域性唯一ID生成演算法，要點如下：

41位的時間序列(精確到毫秒，41位的長度可以使用69年)
10位的機器標識(10位的長度最多支援部署1024個節點)
12位的計數順序號(12位的計數順序號支援每個節點每毫秒產生4096個ID序號)
最高位是符號位，始終為0。
簡單可靠，效能好，趨勢有序，不引入第三方系統。缺點是有使用時間限制，8-100年不等，序列不是連續有序。

如何選擇

在分散式下，考慮到效能，儲存效率和使用方便性，一般不會直接用UUID來做表唯一欄位的ID的。另外UUID有可能洩露MAC地址。

如果沒有分庫的話，用資料庫自增ID是不錯的選擇。

如果有分庫可以使用不同步長的自增ID來避免衝突，如果還有繼續擴容的可能的話，建議直接使用Redis或Snowflake的方案。

如果對連續性有要求的話，建議使用Redis生成方案，如果對連續性沒有要求或者要求乾淨輕爽的方式的話，建議使用Snowflake方案。

另外連續ID有可能洩露業務資訊，根據早晚的ID號，很容易推算出一天的業務量。

Snowflake的改進實現

各開源專案都基於原始演算法做了點改進，比如：處理時間回撥問題，調整各段的位數，使用快取增強併發效能。在虛擬環境下，如k8s下，如何避免多個例項出現相同的worker id等。

比較好的實現有：

我的實現主要是參考了百度的實現。所不同的是，進一步做了簡化，百度使用一個數據庫表來儲存worker id的資訊，每次例項啟動的時候給一個新號，可以支援幾百萬次重啟。我的實現是去掉了資料庫依賴，直接根據機器的IP後24位做worker id。在k8s環境下，網路CIDR預設是-/24，也就是最後24位是不同的，所以用24位IP來做worker id是可以完全避免衝突。相應的，單例每秒的序列號數量有所減少，只有2048個，不過對大部分應用也是夠用的。

另外補充解釋下，為啥要用這麼多位數用於避免worker id重複，實際部署的系統一般也就幾百幾千臺機器/虛擬機器，直接為不同的應用指定不同的id不就完了嗎？這主要是考慮在Spring Cloud或者k8s這樣的環境裡，每個應用是有可能同時開好幾個例項的，如果worker id是硬編碼或者固定配置的，那所有相同應用的例項都會是相同的worker id，肯定會造成UID衝突的。所以就需要有一個渠道能得到唯一的id。那這個渠道在類似k8s這樣的虛擬環境下，無非是資料庫儲存，或者pod ip了。我嫌用資料庫又多引進了一個依賴，希望一個儘可能獨立乾淨的實現，所以我使用ip後24位的方式來做worker id。如果將k8s POD網路的CIDR設成-/16的，那就更完美了，用ip的後16位做唯一worker id，同時把時間位和序列位各加4個，那就可以支援單例每秒32768個序列，連續使用128年了。