在應用程序中，經常需要全局唯一的ID作為數據庫主鍵。如何生成全局唯一ID？
首先，需要確定全局唯一ID是整型還是字符串？如果是字符串，那麼現有的UUID就完全滿足需求，不需要額外的工作。缺點是字符串作為ID佔用空間大，索引效率比整型低。
如果採用整型作為ID，那麼首先排除掉32位int類型，因為範圍太小，必須使用64位long型。
採用整型作為ID時，如何生成自增、全局唯一且不重複的ID？
方案一：利用數據庫的自增ID，從1開始，基本可以做到連續遞增。Oracle可以用SEQUENCE，MySQL可以用主鍵的AUTO_INCREMENT，雖然不能保證全局唯一，但每個表唯一，也基本滿足需求。
數據庫自增ID的缺點是數據在插入前，無法獲得ID。數據在插入後，獲取的ID雖然是唯一的，但一定要等到事務提交後，ID才算是有效的。有些雙向引用的數據，不得不插入後再做一次更新，比較麻煩。
第二種方式是採用一個集中式ID生成器，它可以是Redis，也可以是ZooKeeper，也可以利用數據庫的表記錄最後分配的ID。
這種方式最大的缺點是複雜性太高，需要嚴重依賴第三方服務，而且代碼配置繁瑣。一般來說，越是複雜的方案，越不可靠，並且測試越痛苦。
第三種方式是類似Twitter的Snowflake算法，它給每臺機器分配一個唯一標識，然後通過時間戳+標識+自增實現全局唯一ID。這種方式好處在於ID生成算法完全是一個無狀態機，無網絡調用，高效可靠。缺點是如果唯一標識有重複，會造成ID衝突。
Snowflake算法採用41bit毫秒時間戳，加上10bit機器ID，加上12bit序列號，理論上最多支持1024臺機器每秒生成4096000個序列號，對於Twitter的規模來說夠用了。
但是對於絕大部分普通應用程序來說，根本不需要每秒超過400萬的ID，機器數量也達不到1024臺，所以，我們可以改進一下，使用更短的ID生成方式：
53bitID由32bit秒級時間戳+16bit自增+5bit機器標識組成，累積32臺機器，每秒可以生成6.5萬個序列號，核心代碼：
private static synchronized long nextId(long epochSecond) {
if (epochSecond < lastEpoch) {
// warning: clock is turn back:
logger.warn("clock is back: " + epochSecond + " from previous:" + lastEpoch);
epochSecond = lastEpoch;
}
if (lastEpoch != epochSecond) {
lastEpoch = epochSecond;
reset();
}
offset++;
long next = offset & MAX_NEXT;
if (next == 0) {
logger.warn("maximum id reached in 1 second in epoch: " + epochSecond);
return nextId(epochSecond + 1);
}
return generateId(epochSecond, next, SHARD_ID);
}時間戳減去一個固定值，此方案最高可支持到2106年。
如果每秒6.5萬個序列號不夠怎麼辦？沒關係，可以繼續遞增時間戳，向前“借”下一秒的6.5萬個序列號。
同時還解決了時間回撥的問題。
機器標識採用簡單的主機名方案，只要主機名符合host-1，host-2就可以自動提取機器標識，無需配置。
最後，為什麼採用最多53位整型，而不是64位整型？這是因為考慮到大部分應用程序是Web應用，如果要和JavaScript打交道，由於JavaScript支持的最大整型就是53位，超過這個位數，JavaScript將丟失精度。因此，使用53位整數可以直接由JavaScript讀取，而超過53位時，就必須轉換成字符串才能保證JavaScript處理正確，這會給API接口帶來額外的複雜度。這也是為什麼新浪微博的API接口會同時返回id和idstr的原因。
閱讀更多 架構師的修煉之路 的文章
關鍵字: 全局 MySQL JavaScript
