snowflake
是Twitter開源的分佈式ID生成算法，結果是一個long型的ID。其核心思想是：使用41bit作爲毫秒數，10bit作爲機器的ID（5個bit是數據中心，5個bit的機器ID），12bit作爲毫秒內的流水號（意味着每個節點在每毫秒可以產生 4096 個 ID），最後還有一個符號位，永遠是0
爲什麼使用snowflake？
其實呢如果只是想保證分佈式id的唯一性，那麼使用UUID是完全可以沒問題的，UUID的方式能生成一串唯一隨機32位長度數據，它是無序的一串數據，它是由以太網卡地址、納秒級時間、芯片ID碼和許多可能的數字組成的，所以保證了分佈式不同機器上的id唯一性，但是UUID作爲分佈式唯一ID有一些缺點
1，首先分佈式id一般都會作爲主鍵，但是安裝mysql官方推薦主鍵要儘量越短越好，UUID每一個都很長，所以不是很推薦
2，既然分佈式id是主鍵，然後主鍵是包含索引的，然後mysql的索引是通過b+樹來實現的，每一次新的UUID數據的插入，爲了查詢的優化，都會對索引底層的b+樹進行修改，因爲UUID數據是無序的，所以每一次UUID數據的插入都會對主鍵地城的b+樹進行很大的修改，這一點很不好
3，信息不安全：基於MAC地址生成UUID的算法可能會造成MAC地址泄露，這個漏洞曾被用於尋找梅麗莎病毒的製作者位置。
我們針對第2點說一下：
這裏涉及到b+樹索引分裂：
衆所周知，關係型數據庫的索引大都是B+樹的結構，拿ID字段來舉例，索引樹的每一個節點都存儲着若干個ID。
如果我們的ID按遞增的順序來插入，比如陸續插入8，9，10，新的ID都只會插入到最後一個節點當中。當最後一個節點滿了，會裂變出新的節點。這樣的插入是性能比較高的插入，因爲這樣節點的分裂次數最少，而且充分利用了每一個節點的空間。
但是，如果我們的插入完全無序，不但會導致一些中間節點產生分裂，也會白白創造出很多不飽和的節點，這樣大大降低了數據庫插入的性能。
所以我們可以使用snowflake雪花算法，簡單介紹一下：
SnowFlake所生成的ID一共分成四部分：
1.第一位
佔用1bit，其值始終是0，沒有實際作用。
2.時間戳
佔用41bit，精確到毫秒，總共可以容納約140年的時間。
3.工作機器id
佔用10bit，其中高位5bit是數據中心ID（datacenterId），低位5bit是工作節點ID（workerId），做多可以容納1024個節點。
4.序列號
佔用12bit，這個值在同一毫秒同一節點上從0開始不斷累加，最多可以累加到4095。
SnowFlake算法在同一毫秒內最多可以生成多少個全局唯一ID呢？只需要做一個簡單的乘法：
同一毫秒的ID數量 = 1024 X 4096 = 4194304
這個數字在絕大多數併發場景下都是夠用的。
代碼實現：
public class SnowflakeIdWorker {
// ==============================Fields===========================================
/** 開始時間截 (2015-01-01) */
private final long twepoch = 1420041600000L;
/** 機器id所佔的位數 */
private final long workerIdBits = 5L;
/** 數據標識id所佔的位數 */
private final long datacenterIdBits = 5L;
/** 支持的最大機器id，結果是31 (這個移位算法可以很快的計算出幾位二進制數所能表示的最大十進制數) */
private final long maxWorkerId = -1L ^ (-1L << workerIdBits);
/** 支持的最大數據標識id，結果是31 */
private final long maxDatacenterId = -1L ^ (-1L << 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位(5+5+12) */
private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
/** 生成序列的掩碼，這裏爲4095 (0b111111111111=0xfff=4095) */
private final long sequenceMask = -1L ^ (-1L << sequenceBits);
/** 工作機器ID(0~31) */
private long workerId;
/** 數據中心ID(0~31) */
private long datacenterId;
/** 毫秒內序列(0~4095) */
private long sequence = 0L;
/** 上次生成ID的時間截 */
private long lastTimestamp = -1L;
//==============================Constructors=====================================
/**
* 構造函數
* @param workerId 工作ID (0~31)
* @param datacenterId 數據中心ID (0~31)
*/
public SnowflakeIdWorker(long workerId, long datacenterId) {
if (workerId > maxWorkerId || workerId < 0) {
throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
}
if (datacenterId > maxDatacenterId || datacenterId < 0) {
throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
}
this.workerId = workerId;
this.datacenterId = datacenterId;
}
// ==============================Methods==========================================
/**
* 獲得下一個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 (lastTimestamp == timestamp) {
sequence = (sequence + 1) & sequenceMask;
//毫秒內序列溢出
if (sequence == 0) {
//阻塞到下一個毫秒,獲得新的時間戳
timestamp = tilNextMillis(lastTimestamp);
}
}
//時間戳改變，毫秒內序列重置
else {
sequence = 0L;
}
//上次生成ID的時間截
lastTimestamp = timestamp;
//移位並通過或運算拼到一起組成64位的ID
return ((timestamp - twepoch) << timestampLeftShift) //
| (datacenterId << datacenterIdShift) //
| (workerId << workerIdShift) //
| sequence;
}
/**
* 阻塞到下一個毫秒，直到獲得新的時間戳
* @param lastTimestamp 上次生成ID的時間截
* @return 當前時間戳
*/
protected long tilNextMillis(long lastTimestamp) {
long timestamp = timeGen();
while (timestamp <= lastTimestamp) {
timestamp = timeGen();
}
return timestamp;
}
/**
* 返回以毫秒爲單位的當前時間
* @return 當前時間(毫秒)
*/
protected long timeGen() {
return System.currentTimeMillis();
}
//==============================Test=============================================
/** 測試 */
public static void main(String[] args) {
SnowflakeIdWorker idWorker = new SnowflakeIdWorker(0, 0);
for (int i = 0; i < 1000; i++) {
long id = idWorker.nextId();
System.out.println(Long.toBinaryString(id));
System.out.println(id);
}
}
}
時間回撥問題
分析時間回撥產生原因
第一：人物操作，在真實環境一般不會有那個傻逼幹這種事情，所以基本可以排除。
第二：由於有些業務等需要，機器需要同步時間服務器（在這個過程中可能會存在時間回撥，查了下我們服務器一般在10ms以內（2小時同步一次））。
時間問題回撥的解決方法：
當回撥時間小於15ms，就等時間追上來之後繼續生成。
當時間大於15ms時間我們通過更換workid來產生之前都沒有產生過的來解決回撥問題。
首先把workid的位數進行了調整（15位可以達到3萬多了，一般夠用了）
Snowflake算法稍微調整下位段：
sign(1bit)：固定1bit符號標識，即生成的暢途分佈式唯一id爲正數。
delta seconds (38 bits)：當前時間，相對於時間基點"2017-12-21"的增量值，單位：毫秒，最多可支持約8.716年
worker id (15 bits)：機器id，最多可支持約3.28萬個節點。
sequence (10 bits)：每秒下的併發序列，10 bits，這個算法單機每秒內理論上最多可以生成1000*(2^10)，也就是100W的ID，完全能滿足業務的需求。
由於服務無狀態化關係，所以一般workid也並不配置在具體配置文件裏面，看看我這篇的思考，爲什麼需要無狀態化。高可用的一些思考和理解，這裏我們選擇redis來進行中央存儲（zk、db）都是一樣的，只要是集中式的就可以。
下面到了關鍵了：
現在我把3萬多個workid放到一個隊列中（基於redis），由於需要一個集中的地方來管理workId，每當節點啓動時候，（先在本地某個地方看看是否有 借鑑弱依賴zk 本地先保存），如果有那麼值就作爲workid，如果不存在，就在隊列中取一個當workid來使用（隊列取走了就沒了 ），當發現時間回撥太多的時候，我們就再去隊列取一個來當新的workid使用，把剛剛那個使用回撥的情況的workid存到隊列裏面（隊列我們每次都是從頭取，從尾部進行插入，這樣避免剛剛a機器使用又被b機器獲取的可能性）。