背景
在復雜分布式系統中,往往需要對大量的數據和消息進行唯一標識。如在支付流水號、訂單號等,隨者業務數據日漸增長,對數據分庫分表后需要有一個唯一ID來標識一條數據或消息,數據庫的自增ID顯然不能滿足需求,此時一個能夠生成全局唯一ID的系統是非常必要的。
生成的唯一id需要具備哪些條件
全局唯一性:不能出現重復的ID號,既然是唯一標識,這是最基本的要求。
趨勢遞增:在MySQL InnoDB引擎中使用的是聚集索引,由于多數RDBMS使用B-tree的數據結構來存儲索引數據,在主鍵的選擇上面我們應該盡量使用有序的主鍵保證寫入性能。
單調遞增:保證下一個ID一定大于上一個ID,例如事務版本號、IM增量消息、排序等特殊需求。
信息安全:如果ID是連續的,惡意用戶的扒取工作就非常容易做了,直接按照順序下載指定URL即可;如果是訂單號就更危險了,競對可以直接知道我們一天的單量。所以在一些應用場景下,會需要ID無規則、不規則。
UUID
關于分布式id,很多人會想到使用UUID,UUID在唯一性上確實可以達到這個目的,但它也存在很大的缺陷
優點:
性能非常高:本地生成,沒有網絡消耗。
缺點:
不易于存儲:UUID太長,16字節128位,通常以36長度的字符串表示,很多場景不適用。
信息不安全:基于MAC地址生成UUID的算法可能會造成MAC地址泄露,這個漏洞曾被用于尋找梅麗莎病毒的制作者位置。
ID作為主鍵時在特定的環境會存在一些問題,比如做DB主鍵的場景下,UUID就非常不適用。(MySQL官方有明確的建議主鍵要盡量越短越好,36個字符長度的UUID不符合要求。對MySQL索引不利:如果作為數據庫主鍵,在InnoDB引擎下,UUID的無序性可能會引起數據位置頻繁變動,嚴重影響性能。)
snowflake
"世界上沒有一片雪花是相同的",這大概是snowflake名字的由來吧。
SnowFlake算法是Twitter設計的一個可以在分布式系統中生成唯一的ID的算法,它可以滿足Twitter每秒上萬條消息ID分配的請求,這些消息ID是唯一的且有大致的遞增順序。
snowflake算法的原理
SnowFlake算法產生的ID是一個64位的整型,結構如下(每一部分用“-”符號分隔):
snowflake.png
需要注意的是64位是二進制,2的64次方 = 18446744073709551616,這就是能表示的id的范圍,范圍可以通過擴展序列號或則工作機器id來增加id的上限。
1位標識部分
在java中由于long的最高位是符號位,正數是0,負數是1,一般生成的ID為正數,所以為0;
41位時間戳部分
這個是毫秒級的時間,一般實現上不會存儲當前的時間戳,而是時間戳的差值(當前時間-固定的開始時間),這樣可以使產生的ID從更小值開始;41位的時間戳可以使用69年,(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年;
10位節點部分
Twitter實現中使用前5位作為數據中心標識,后5位作為機器標識,可以部署1024個節點,在Spring Cloud中可以為每一個實例生成唯一的機器識別碼,這樣就能保證每個實例中生成的id都不一樣。
12位序列號部分
支持同一毫秒內同一個節點可以生成4096(2的12次方)個ID,這個同樣可以擴展,但其實每毫秒生成4096個id已經能滿足大部分場景了。
算法的java代碼
/**
* twitter的snowflake算法 -- java實現
*
* @author beyond
* @date 2016/11/26
*/
public class SnowFlake {
/**
* 起始的時間戳(最后的時間 = 當前時間戳 - 起始的時間戳)
*/
private final static long START_STMP = 1480166465631L;
/**
* 每一部分占用的位數
*/
private final static long SEQUENCE_BIT = 12; //序列號占用的位數
private final static long MACHINE_BIT = 5; //機器標識占用的位數
private final static long DATACENTER_BIT = 5;//數據中心占用的位數
/**
* 每一部分的最大值
*/
private final static long MAX_DATACENTER_NUM = -1L ^ (-1L << DATACENTER_BIT);
private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);
/**
* 每一部分向左的位移
*/
private final static long MACHINE_LEFT = SEQUENCE_BIT;
private final static long DATACENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
private final static long TIMESTMP_LEFT = DATACENTER_LEFT + DATACENTER_BIT;
private long datacenterId; //數據中心
private long machineId; //機器標識
private long sequence = 0L; //序列號
private long lastStmp = -1L;//上一次時間戳
public SnowFlake(long datacenterId, long machineId) {
// 校驗datacenterId長度超過范圍就拋異常
if (datacenterId > MAX_DATACENTER_NUM || datacenterId < 0) {
throw new IllegalArgumentException("datacenterId can't be greater than MAX_DATACENTER_NUM or less than 0");
}
// 校驗machineId長度超過范圍就拋異常
if (machineId > MAX_MACHINE_NUM || machineId < 0) {
throw new IllegalArgumentException("machineId can't be greater than MAX_MACHINE_NUM or less than 0");
}
this.datacenterId = datacenterId;
this.machineId = machineId;
}
/**
* 產生下一個ID
*
* @return
*/
public synchronized long nextId() {
long currStmp = getNewstmp();
if (currStmp < lastStmp) {
throw new RuntimeException("Clock moved backwards. Refusing to generate id");
}
if (currStmp == lastStmp) {
//相同毫秒內,序列號自增
sequence = (sequence + 1) & MAX_SEQUENCE;
//同一毫秒的序列數已經達到最大
if (sequence == 0L) {
currStmp = getNextMill();
}
} else {
//不同毫秒內,序列號置為0
sequence = 0L;
}
lastStmp = currStmp;
//使用二進制的"|"運算符將4部分的值整合成我們需要的id
return (currStmp - START_STMP) << TIMESTMP_LEFT //時間戳部分
| datacenterId << DATACENTER_LEFT //數據中心部分
| machineId << MACHINE_LEFT //機器標識部分
| sequence; //序列號部分
}
//如果當前毫秒值下的序列號用完,就循環獲取下個毫秒值,如果沒有獲取到下個毫秒值就
//一直循環下去
private long getNextMill() {
long mill = getNewstmp();
while (mill <= lastStmp) {
mill = getNewstmp();
}
return mill;
}
private long getNewstmp() {
return System.currentTimeMillis();
}
public static void main(String[] args) {
SnowFlake snowFlake = new SnowFlake(2, 3);
for (int i = 0; i < (1 << 12); i++) {
System.out.println(snowFlake.nextId());
}
}
}
總結
10位節點部分在代碼中分成了兩個5位節點,看具體需求,也可以用一個10位節點代替。snowflake更多的是提供一種算法思想,具體的id生成邏輯可以在此基礎上進一步的優化。