用戶UID的幾種生成方案

本文目的是介紹市面上流行的UID生成方式、優劣狀況，幫助讀者根據本身的產品類型和用戶規模選擇合適的生成方案。

什麼是UID?

UID是一個系統內用戶的惟一標識，

UID的特性: 惟一性、可公開廣播、存在可能價值等。

惟一性

經過UID能夠快速映射到一個具體的惟一用戶上，相似於hash、短網址映射。

可公開廣播

UID能夠和用戶的帳號造成對應關係。對於某些以手機號、郵箱這些隱私內容爲登陸帳號的系統，若是想增長轉帳這種業務，輸入對方的UID，能夠作到隱私保護。

存在可能價值

相似QQ靚號、B站短ID、微博ID這種能夠存在部分價值。

流行的生成方式

1. 隨機生成-普通查重模式
2. 經典表ID自增模式
3. 號池模式
4. 隨機生成-查重模式-加位法
5. 類Snowflake模式
6. UUID模式

隨機生成-普通查重模式

使用rand函數隨機成生結果，再去user表上查重，不重複就做爲用戶的UID，重複則繼續rand到不重複爲止。

優勢: 生成速度快、邏輯簡單、生成號段格式能夠經過過濾器控制。
缺點: 當用戶總數變高的時候，重複率會變高。
適用: 用戶總量不會很高，對於靚號沒有什麼要求。

經典表ID自增

將user表的id設置爲auto_increment，插入會自動生成ID，將表的主鍵ID做爲UID.

優勢: 不須要主動管理，自動生成，不會重複。
缺點: 容易暴露系統的真實用戶數，不適合須要良好數據的商業公司。
適用: 普通的社區、博客內容等不關注UID模式的系統。

號池模式

生成一批UID存放到號池內， 註冊一個取走一個。

優勢: 對於靚號的控制精準、號池控制得當的話，不會發生重複。
缺點: 對於號池服務的穩定性很高, 對於號池內數據的增長和刪除須要主動管理，不然會發生重複。
適用: 對靚號要求控制嚴格，適用於通常的等級榮譽感、靚號榮譽感較高的玩家社區。

隨機生成-查重模式-加位法

加位查重法是普通查重法的升級，當碰到了重複號碼的時候，向號碼尾部增長一個隨機數字，若是重複就繼續增長，直到不重複爲止。

優勢: 相對於普通查重法，重複後的再次獲取次數能夠減小
缺點: 重複後再獲取率隨着用戶數上升，也會遭遇瓶頸。
適用: 同普通查重模式。

類Snowflake模式

Snowflake是一個經典的號段生成算法，同時市面上存在大量的XXXflake算法.通常用做訂單號。 主要講一下Snowflake的原理

使用41bit做爲毫秒數，10bit做爲機器的ID（5個bit是數據中心，5個bit的機器ID），12bit做爲毫秒內的流水號，最後還有一個符號位，永遠是0

優勢: 不須要主動管理就可保證防重性，能夠根據業務配比調整bit。
缺點: 生成的數據結果比較長，索引須要主動優化。
適用: 不存在UID靚號需求

UUID模式

UUID是一個國際標準算法，具體介紹就不贅述了，優缺點和類Snowflake一致

優勢: 不須要主動管理就可保證防重性。
缺點: 生成的數據結果比較長，索引須要主動優化。
適用: 不存在UID靚號需求

總結

通常對於預計百萬用戶之內的系統，將UID設置爲10位，使用隨機成產-普通查重模式便可。查重基本上不會損耗過多性能，還能夠根據過濾器過濾掉靚號，基本上能夠解決大部分的業務需求。

對於預計超過百萬的用戶，最重要的是關注業務對於UID的依賴和靚號的需求，選擇合適的方案。