分布式唯一ID的幾種生成方案
在互聯網的業務系統中,涉及到各種各樣的ID,如在支付系統中就會有支付ID、退款ID等。那一般生成ID都有哪些解決方案呢?特別是在復雜的分布式系統業務場景中,我們應該采用哪種適合自己的解決方案是十分重要的。下面我們一一來列舉一下,不一定全部適合,這些解決方案僅供你參考,或許對你有用。
正文
分布式ID的特性
唯一性:確保生成的ID是全網唯一的。
有序遞增性:確保生成的ID是對於某個用戶或者業務是按一定的數字有序遞增的。
高可用性:確保任何時候都能正確的生成ID。
帶時間:ID裏面包含時間,一眼掃過去就知道哪天的交易。
分布式ID的生成方案
1. UUID
算法的核心思想是結合機器的網卡、當地時間、一個隨記數來生成UUID。
優點:本地生成,生成簡單,性能好,沒有高可用風險
缺點:長度過長,存儲冗余,且無序不可讀,查詢效率低
2. 數據庫自增ID
使用數據庫的id自增策略,如 MySQL 的 auto_increment。並且可以使用兩臺數據庫分別設置不同步長,生成不重復ID的策略來實現高可用。
優點:數據庫生成的ID絕對有序,高可用實現方式簡單
缺點:需要獨立部署數據庫實例,成本高,有性能瓶頸
3. 批量生成ID
一次按需批量生成多個ID,每次生成都需要訪問數據庫,將數據庫修改為最大的ID值,並在內存中記錄當前值及最大值。
優點:避免了每次生成ID都要訪問數據庫並帶來壓力,提高性能
缺點:屬於本地生成策略,存在單點故障,服務重啟造成ID不連續
4. Redis生成ID
Redis的所有命令操作都是單線程的,本身提供像 incr 和 increby 這樣的自增原子命令,所以能保證生成的 ID 肯定是唯一有序的。
優點:不依賴於數據庫,靈活方便,且性能優於數據庫;數字ID天然排序,對分頁或者需要排序的結果很有幫助。
缺點:如果系統中沒有Redis,還需要引入新的組件,增加系統復雜度;需要編碼和配置的工作量比較大。
考慮到單節點的性能瓶頸,可以使用 Redis 集群來獲取更高的吞吐量。假如一個集群中有5臺 Redis。可以初始化每臺 Redis 的值分別是1, 2, 3, 4, 5,然後步長都是 5。各個 Redis 生成的 ID 為:
A:1, 6, 11, 16, 21 B:2, 7, 12, 17, 22 C:3, 8, 13, 18, 23 D:4, 9, 14, 19, 24 E:5, 10, 15, 20, 25
隨便負載到哪個機確定好,未來很難做修改。步長和初始值一定需要事先確定。使用 Redis 集群也可以方式單點故障的問題。
另外,比較適合使用 Redis 來生成每天從0開始的流水號。比如訂單號 = 日期 + 當日自增長號。可以每天在 Redis 中生成一個 Key ,使用 INCR 進行累加。
5. Twitter的snowflake算法
Twitter 利用 zookeeper 實現了一個全局ID生成的服務 Snowflake:github.com/twitter/sno…
https://user-gold-cdn.xitu.io/2018/7/2/1645b1a7a9beb2b6?imageslim
如上圖的所示,Twitter 的 Snowflake 算法由下面幾部分組成:
1位符號位:
由於 long 類型在 java 中帶符號的,最高位為符號位,正數為 0,負數為 1,且實際系統中所使用的ID一般都是正數,所以最高位為 0。
41位時間戳(毫秒級):
需要註意的是此處的 41 位時間戳並非存儲當前時間的時間戳,而是存儲時間戳的差值(當前時間戳 - 起始時間戳),這裏的起始時間戳一般是ID生成器開始使用的時間戳,由程序來指定,所以41位毫秒時間戳最多可以使用 (1 << 41) / (1000x60x60x24x365) = 69年。
10位數據機器位:
包括5位數據標識位和5位機器標識位,這10位決定了分布式系統中最多可以部署 1 << 10 = 1024 s個節點。超過這個數量,生成的ID就有可能會沖突。
12位毫秒內的序列:
這 12 位計數支持每個節點每毫秒(同一臺機器,同一時刻)最多生成 1 << 12 = 4096個ID
加起來剛好64位,為一個Long型。
優點:高性能,低延遲,按時間有序,一般不會造成ID碰撞
缺點:需要獨立的開發和部署,依賴於機器的時鐘
簡單實現
public class IdWorker {
/**
* 起始時間戳 2017-04-01
*/
private final long epoch = 1491004800000L;
/**
* 機器ID所占的位數
*/
private final long workerIdBits = 5L;
/**
* 數據標識ID所占的位數
*/
private final long dataCenterIdBits = 5L;
/**
* 支持的最大機器ID,結果是31
*/
private final long maxWorkerId = ~(-1L << workerIdBits);
/**
* 支持的最大數據標識ID,結果是31
*/
private final long maxDataCenterId = ~(-1 << dataCenterIdBits);
/**
* 毫秒內序列在id中所占的位數
*/
private final long sequenceBits = 12L;
/**
* 機器ID向左移12位
*/
private final long workerIdShift = sequenceBits;
/**
* 數據標識ID向左移17(12+5)位
*/
private final long dataCenterIdShift = sequenceBits + workerIdBits;
/**
* 時間戳向左移22(12+5+5)位
*/
private final long timestampShift = sequenceBits + workerIdBits + dataCenterIdBits;
/**
* 生成序列的掩碼,這裏為4095 (0b111111111111=0xfff=4095)
*/
private final long sequenceMask = ~(-1L << sequenceBits);
/**
* 數據標識ID(0~31)
*/
private long dataCenterId;
/**
* 機器ID(0~31)
*/
private long workerId;
/**
* 毫秒內序列(0~4095)
*/
private long sequence;
/**
* 上次生成ID的時間戳
*/
private long lastTimestamp = -1L;
public IdWorker(long dataCenterId, long workerId) {
if (dataCenterId > maxDataCenterId || dataCenterId < 0) {
throw new IllegalArgumentException(String.format("dataCenterId can‘t be greater than %d or less than 0", maxDataCenterId));
}
if (workerId > maxWorkerId || workerId < 0) {
throw new IllegalArgumentException(String.format("worker Id can‘t be greater than %d or less than 0", maxWorkerId));
}
this.dataCenterId = dataCenterId;
this.workerId = workerId;
}
/**
* 獲得下一個ID (該方法是線程安全的)
* @return snowflakeId
*/
public synchronized long nextId() {
long timestamp = timeGen();
//如果當前時間小於上一次ID生成的時間戳,說明系統時鐘回退過,這個時候應當拋出異常
if (timestamp < lastTimestamp) {
throw new RuntimeException(String.format("Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
}
//如果是同一時間生成的,則進行毫秒內序列
if (timestamp == lastTimestamp) {
sequence = (sequence + 1) & sequenceMask;
//毫秒內序列溢出
if (sequence == 0) {
//阻塞到下一個毫秒,獲得新的時間戳
timestamp = nextMillis(lastTimestamp);
}
} else {//時間戳改變,毫秒內序列重置
sequence = 0L;
}
lastTimestamp = timestamp;
//移位並通過按位或運算拼到一起組成64位的ID
return ((timestamp - epoch) << timestampShift) |
(dataCenterId << dataCenterIdShift) |
(workerId << workerIdShift) |
sequence;
}
/**
* 返回以毫秒為單位的當前時間
* @return 當前時間(毫秒)
*/
protected long timeGen() {
return System.currentTimeMillis();
}
/**
* 阻塞到下一個毫秒,直到獲得新的時間戳
* @param lastTimestamp 上次生成ID的時間截
* @return 當前時間戳
*/
protected long nextMillis(long lastTimestamp) {
long timestamp = timeGen();
while (timestamp <= lastTimestamp) {
timestamp = lastTimestamp;
}
return timestamp;
}
}
6. 百度UidGenerator
UidGenerator是百度開源的分布式ID生成器,基於於snowflake算法的實現,看起來感覺還行。不過,國內開源的項目維護性真是擔憂。
具體可以參考官網說明:github.com/baidu/uid-g…
7. 美團Leaf
Leaf 是美團開源的分布式ID生成器,能保證全局唯一性、趨勢遞增、單調遞增、信息安全,裏面也提到了幾種分布式方案的對比,但也需要依賴關系數據庫、Zookeeper等中間件。
具體可以參考官網說明:tech.meituan.com/MT_Leaf.htm…
小結
這篇文章和大家分享了全局id生成服務的幾種常用方案,同時對比了各自的優缺點和適用場景。在實際工作中,大家可以結合自身業務和系統架構體系進行合理選型。
分布式唯一ID的幾種生成方案