基於Twitter的Snowflake算法實現分布式高效有序ID生產黑科技（無懈可擊）

參考美團文檔：https://tech.meituan.com/2017/04/21/mt-leaf.html

Twitter-Snowflake算法產生的背景相當簡單，為了滿足Twitter每秒上萬條消息的請求，每條消息都必須分配一條唯一的id，這些id還需要一些大致的順序（方便客戶端排序），並且在分布式系統中不同機器產生的id必須不同。

性能測試數據：

Snowflake算法核心

把時間戳，工作機器id，序列號組合在一起。

41-bit的時間可以表示（1L<<41）/(1000L*3600*24*365)=69年的時間，10-bit機器可以分別表示1024台機器。如果我們對IDC划分有需求，還可以將10-bit分5-bit給IDC，分5-bit給工作機器。這樣就可以表示32個IDC，每個IDC下可以有32台機器，可以根據自身需求定義。12個自增序列號可以表示2^12個ID，理論上snowflake方案的QPS約為409.6w/s，這種分配方式可以保證在任何一個IDC的任何一台機器在任意毫秒內生成的ID都是不同的。

這種方式的優缺點是：

優點：

• 毫秒數在高位，自增序列在低位，整個ID都是趨勢遞增的。
• 不依賴數據庫等第三方系統，以服務的方式部署，穩定性更高，生成ID的性能也是非常高的。
• 可以根據自身業務特性分配bit位，非常靈活。

缺點：

• 強依賴機器時鍾，如果機器上時鍾回撥，會導致發號重復或者服務會處於不可用狀態。

 

package cn.ms.sequence;


/**
 * 基於Twitter的Snowflake算法實現分布式高效有序ID生產黑科技(sequence)
 * 
 * <br>
 * SnowFlake的結構如下(每部分用-分開):<br>
 * <br>
 * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br>
 * <br>
 * 1位標識，由於long基本類型在Java中是帶符號的，最高位是符號位，正數是0，負數是1，所以id一般是正數，最高位是0<br>
 * <br>
 * 41位時間截(毫秒級)，注意，41位時間截不是存儲當前時間的時間截，而是存儲時間截的差值（當前時間截 - 開始時間截)
 * 得到的值），這里的的開始時間截，一般是我們的id生成器開始使用的時間，由我們程序來指定的（如下下面程序IdWorker類的startTime屬性）。41位的時間截，可以使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br>
 * <br>
 * 10位的數據機器位，可以部署在1024個節點，包括5位datacenterId和5位workerId<br>
 * <br>
 * 12位序列，毫秒內的計數，12位的計數順序號支持每個節點每毫秒(同一機器，同一時間截)產生4096個ID序號<br>
 * <br>
 * <br>
 * 加起來剛好64位，為一個Long型。<br>
 * SnowFlake的優點是，整體上按照時間自增排序，並且整個分布式系統內不會產生ID碰撞(由數據中心ID和機器ID作區分)，並且效率較高，經測試，SnowFlake每秒能夠產生26萬ID左右。
 * 
 * @author lry
 */
public class Sequence {

    /** 起始時間戳，用於用當前時間戳減去這個時間戳，算出偏移量 **/
    private final long startTime = 1519740777809L;

    /** workerId占用的位數5（表示只允許workId的范圍為：0-1023）**/
    private final long workerIdBits = 5L;
    /** dataCenterId占用的位數：5 **/
    private final long dataCenterIdBits = 5L;
    /** 序列號占用的位數：12（表示只允許workId的范圍為：0-4095）**/
    private final long sequenceBits = 12L;

    /** workerId可以使用的最大數值：31 **/
    private final long maxWorkerId = -1L ^ (-1L << workerIdBits);
    /** dataCenterId可以使用的最大數值：31 **/
    private final long maxDataCenterId = -1L ^ (-1L << dataCenterIdBits);

    private final long workerIdShift = sequenceBits;
    private final long dataCenterIdShift = sequenceBits + workerIdBits;
    private final long timestampLeftShift = sequenceBits + workerIdBits + dataCenterIdBits;

    /** 用mask防止溢出:位與運算保證計算的結果范圍始終是 0-4095 **/
    private final long sequenceMask = -1L ^ (-1L << sequenceBits);

    private long workerId;
    private long dataCenterId;
    private long sequence = 0L;
    private long lastTimestamp = -1L;
    private boolean isClock = false;

    /**
     * 基於Snowflake創建分布式ID生成器
     * <p>
     * 注：sequence
     *
     * @param workerId     工作機器ID,數據范圍為0~31
     * @param dataCenterId 數據中心ID,數據范圍為0~31
     */
    public Sequence(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;
    }

    public void setClock(boolean clock) {
        isClock = clock;
    }

    /**
     * 獲取ID
     *
     * @return
     */
    public synchronized Long nextId() {
        long timestamp = this.timeGen();

        // 閏秒：如果當前時間小於上一次ID生成的時間戳，說明系統時鍾回退過這個時候應當拋出異常
        if (timestamp < lastTimestamp) {
            long offset = lastTimestamp - timestamp;
            if (offset <= 5) {
                try {
                    this.wait(offset << 1);
                    timestamp = this.timeGen();
                    if (timestamp < lastTimestamp) {
                        throw new RuntimeException(String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", offset));
                    }
                } catch (Exception e) {
                    throw new RuntimeException(e);
                }
            } else {
                throw new RuntimeException(String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", offset));
            }
        }

        // 解決跨毫秒生成ID序列號始終為偶數的缺陷:如果是同一時間生成的，則進行毫秒內序列
        if (lastTimestamp == timestamp) {
            // 通過位與運算保證計算的結果范圍始終是 0-4095
            sequence = (sequence + 1) & sequenceMask;
            if (sequence == 0) {
                timestamp = this.tilNextMillis(lastTimestamp);
            }
        } else {
            // 時間戳改變，毫秒內序列重置
            sequence = 0L;
        }

        lastTimestamp = timestamp;

        /*
         * 1.左移運算是為了將數值移動到對應的段(41、5、5，12那段因為本來就在最右，因此不用左移)
         * 2.然后對每個左移后的值(la、lb、lc、sequence)做位或運算，是為了把各個短的數據合並起來，合並成一個二進制數
         * 3.最后轉換成10進制，就是最終生成的id
         */
        return ((timestamp - startTime) << timestampLeftShift) |
                (dataCenterId << dataCenterIdShift) |
                (workerId << workerIdShift) |
                sequence;
    }

    /**
     * 保證返回的毫秒數在參數之后(阻塞到下一個毫秒，直到獲得新的時間戳)
     *
     * @param lastTimestamp
     * @return
     */
    private long tilNextMillis(long lastTimestamp) {
        long timestamp = this.timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = this.timeGen();
        }

        return timestamp;
    }

    /**
     * 獲得系統當前毫秒數
     *
     * @return timestamp
     */
    private long timeGen() {
        if (isClock) {
            // 解決高並發下獲取時間戳的性能問題
            return SystemClock.now();
        } else {
            return System.currentTimeMillis();
        }
    }

}

package cn.ms.sequence;

import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;

/**
 * 高並發場景下System.currentTimeMillis()的性能問題的優化
 * <p><p>
 * System.currentTimeMillis()的調用比new一個普通對象要耗時的多（具體耗時高出多少我還沒測試過，有人說是100倍左右）<p>
 * System.currentTimeMillis()之所以慢是因為去跟系統打了一次交道<p>
 * 后台定時更新時鍾，JVM退出時，線程自動回收<p>
 * 10億：43410,206,210.72815533980582%<p>
 * 1億：4699,29,162.0344827586207%<p>
 * 1000萬：480,12,40.0%<p>
 * 100萬：50,10,5.0%<p>
 *
 * @author lry
 */
public class SystemClock {

    private final long period;
    private final AtomicLong now;

    private SystemClock(long period) {
        this.period = period;
        this.now = new AtomicLong(System.currentTimeMillis());
        scheduleClockUpdating();
    }

    private static class InstanceHolder {
        public static final SystemClock INSTANCE = new SystemClock(1);
    }

    private static SystemClock instance() {
        return InstanceHolder.INSTANCE;
    }

    private void scheduleClockUpdating() {
        ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor(runnable -> {
            Thread thread = new Thread(runnable, "system-clock");
            thread.setDaemon(true);
            return thread;
        });
        scheduler.scheduleAtFixedRate(() -> now.set(System.currentTimeMillis()), period, period, TimeUnit.MILLISECONDS);
    }

    private long currentTimeMillis() {
        return now.get();
    }

    public static long now() {
        return instance().currentTimeMillis();
    }

    public static String nowDate() {
        return String.valueOf(now());
    }

}

測試類：

package cn.ms.sequence;

import org.databene.contiperf.PerfTest;
import org.databene.contiperf.junit.ContiPerfRule;
import org.junit.Rule;
import org.junit.Test;

/**
 * 性能測試
 *
 * @author lry
 */
public class ContiPerfTest {

    @Rule
    public ContiPerfRule i = new ContiPerfRule();

    Sequence sequence = new Sequence(0, 0);


    @Test
    @PerfTest(invocations = 500, threads = 100)
    public void test1() throws Exception {
        System.out.println(sequence.nextId());
    }

}

測試結果如下：

 

弱依賴ZooKeeper

除了每次會去ZK拿數據以外，也會在本機文件系統上緩存一個workerID文件。當ZooKeeper出現問題，恰好機器出現問題需要重啟時，能保證服務能夠正常啟動。這樣做到了對三方組件的弱依賴。一定程度上提高了SLA

解決時鍾問題

因為這種方案依賴時間，如果機器的時鍾發生了回撥，那么就會有可能生成重復的ID號，需要解決時鍾回退的問題。

參見上圖整個啟動流程圖，服務啟動時首先檢查自己是否寫過ZooKeeper leaf_forever節點：

1. 若寫過，則用自身系統時間與leaf_forever/${self}節點記錄時間做比較，若小於leaf_forever/${self}時間則認為機器時間發生了大步長回撥，服務啟動失敗並報警。
2. 若未寫過，證明是新服務節點，直接創建持久節點leaf_forever/${self}並寫入自身系統時間，接下來綜合對比其余Leaf節點的系統時間來判斷自身系統時間是否准確，具體做法是取leaf_temporary下的所有臨時節點(所有運行中的Leaf-snowflake節點)的服務IP：Port，然后通過RPC請求得到所有節點的系統時間，計算sum(time)/nodeSize。
3. 若abs( 系統時間-sum(time)/nodeSize ) < 閾值，認為當前系統時間准確，正常啟動服務，同時寫臨時節點leaf_temporary/${self} 維持租約。
4. 否則認為本機系統時間發生大步長偏移，啟動失敗並報警。
5. 每隔一段時間(3s)上報自身系統時間寫入leaf_forever/${self}。

由於強依賴時鍾，對時間的要求比較敏感，在機器工作時NTP同步也會造成秒級別的回退，建議可以直接關閉NTP同步。要么在時鍾回撥的時候直接不提供服務直接返回ERROR_CODE，等時鍾追上即可。或者做一層重試，然后上報報警系統，更或者是發現有時鍾回撥之后自動摘除本身節點並報警，如下：

 //發生了回撥，此刻時間小於上次發號時間
 if (timestamp < lastTimestamp) {
                
            long offset = lastTimestamp - timestamp;
            if (offset <= 5) {
                try {
                    //時間偏差大小小於5ms，則等待兩倍時間
                    wait(offset << 1);//wait
                    timestamp = timeGen();
                    if (timestamp < lastTimestamp) {
                       //還是小於，拋異常並上報
                        throwClockBackwardsEx(timestamp);
                      }    
                } catch (InterruptedException e) {  
                   throw  e;
                }
            } else {
                //throw
                throwClockBackwardsEx(timestamp);
            }
        }
 //分配ID       
        

從上線情況來看，在2017年閏秒出現那一次出現過部分機器回撥，由於Leaf-snowflake的策略保證，成功避免了對業務造成的影響。