一、概述
分佈式 ID 生成算法的有很多種，Twitter 的 SnowFlake 就是其中經典的一種。
SnowFlake 算法生成 ID 的結果是一個 64bit 大小的整數，它的結構如下圖：
- 1 位，不用。二進制中最高位爲 1 的都是負數，但是我們生成的 id 一般都使用整數，所以這個最高位固定是 0。
- 41 位，用來記錄時間戳（毫秒）。41 位可以表示 2^41 個數字；如果只用來表示正整數（計算機中正數包含 0），可以表示的數值範圍是：0 至 2^41−1，也就是說 41 位可以表示 2^41 個毫秒的值，轉化成單位年則是 2^41 / (1000 * 60 * 60 * 24 * 365) = 69年。
- 10 位，用來記錄工作機器 id，可以部署在 2^10 = 1024個節點，包括 5 位 datacenterId 和 5 位 workerId ；5 位（bit）可以表示的最大正整數是2^5-1 = 31，即可以用 0、1、2、3、....31 這 32 個數字，來表示不同的 datecenterId 或 workerId。
- 12 位，序列號，用來記錄同毫秒內產生的不同 id。12位（bit）可以表示的最大正整數是 2^12-1 =4095，即可以用 0、1、2、3、....4095 這 4096 個數字，來表示同一機器同一時間截（毫秒）內產生的 4096 個ID序號。
由於在 Java 中 64 bit 的整數是 Long 類型，所以在 Java 中 SnowFlake 算法生成的 ID 就是 Long 來存儲的。
SnowFlake 可以保證：
- 所有生成的 ID 按時間趨勢遞增；
- 整個分佈式系統內不會產生重複id（因爲有 datacenterId 和 workerId 來做區分）；
二、SnowFlake 算法的 JAVA 實現
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 << DATACENTER_BIT);
private final static long MAX_MACHINE_NUM = ~(-1L << MACHINE_BIT);
private final static long MAX_SEQUENCE = ~(-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) {
if (datacenterId > MAX_DATACENTER_NUM || datacenterId < 0) {
throw new IllegalArgumentException("datacenterId can't be greater than MAX_DATACENTER_NUM or less than 0");
}
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;
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);
long start = System.currentTimeMillis();
for (int i = 0; i < 1000; i++) {
System.out.println(snowFlake.nextId());
}
System.out.println(System.currentTimeMillis() - start);
}
}
三、SnowFlake 算法的生產實踐
通過前面的講述我們知道 SnowFlake 算法能產生全局唯一 ID 主要是通過 5 位 datacenterId 和 5 位 workerId 來做區分，而在生產實踐中，我們常常將機器 ID（hostid）來當成 datacenterId，將機器上運行的實例ID（pid）來當成 workerId。
如今的分佈式部署都在強調無狀態化，那麼給每臺機器綁定一個 hostid 顯然不太現實，假設又是在容器化環境下，沒有固定的 IP，並且容器實例每次重新啓動後的唯一 ID 還不一致。綜上，基於機器 ID 的思路不可行。所以經常的做法是，利用 ZK/Redis/DB 等作爲一個全局的 datacenterId/workerId 發號器，由發號器來分配唯一的 datacenterId/workerId 。（可以參考百度分佈式唯一 ID 生成器 UidGenerator）
四、SnowFlake 算法的問題思考
1. 時間回撥問題
由於機器的時間是動態的調整的，有可能會出現時間跑到之前幾毫秒，如果這個時候獲取到了這種時間，則會出現數據重複。
這個問題的解決方案是採用“歷史時間”。在進程啓動後，我們會將當前時間（實際處理採用了延遲10ms啓動），作爲該業務這臺機器進程的時間戳中的起始時間字段，後續的自增是在序列號自增到最大值時，時間戳增 1，而序列號重新歸爲 0。
2. 機器 id 分配及回收
目前機器 id 需要每臺機器不一樣，這樣的方式分配需要有方案進行處理，同時也要考慮，如果該機器宕機了，對應的 datacenterId/workerId 分配後的回收問題。
這個問題的解決方案是：每個實例啓動，擴容，直接從 ZK/Redis/DB 等發號器取一個 id 作爲 datacenterId/workerId，下線不銷燬；並且維護一個活動節點隊列，在地址空間耗盡的時候，指針指回隊列頭部，當分配的 id 存在於活動節點隊列則跳過取下一個可用空間，達到複用原地址空間的目的。
