冷飯新炒：理解Snowflake演算法的實現原理

throwable發表於2020-08-10
演算法

前提

Snowflake（雪花）是Twitter開源的高效能ID生成演算法（服務）。

上圖是Snowflake的Github倉庫，master分支中的REAEMDE檔案中提示：初始版本於2010年釋出，基於Apache Thrift，早於Finagle（這裡的Finagle是Twitter上用於RPC服務的構建模組）釋出，而Twitter內部使用的Snowflake是一個完全重寫的程式，在很大程度上依靠Twitter上的現有基礎架構來執行。

而2010年釋出的初版Snowflake原始碼是使用Scala語言編寫的，歸檔於scala_28分支。換言之，大家目前使用的Snowflake演算法原版或者改良版已經是十年前（當前是2020年）的產物，不得不說這個演算法確實比較厲害。scala_28分支中有介紹該演算法的動機和要求，這裡簡單摘錄一下：

動機：

  • Cassandra中沒有生成順序ID的工具，Twitter由使用MySQL轉向使用Cassandra的時候需要一種新的方式來生成ID（印證了架構不是設計出來，而是基於業務場景迭代出來）。

要求：

  • 高效能：每秒每個程式至少產生10K個ID，加上網路延遲響應速度要在2ms內。
  • 順序性：具備按照時間的自增趨勢，可以直接排序。
  • 緊湊性：保持生成的ID的長度在64 bit或更短。
  • 高可用：ID生成方案需要和儲存服務一樣高可用。

下面就Snowflake的原始碼分析一下他的實現原理。

Snowflake方案簡述

Snowflake在初版設計方案是：

  • 時間：41 bit長度，使用毫秒級別精度，帶有一個自定義epoch，那麼可以使用大概69年。
  • 可配置的機器ID：10 bit長度，可以滿足1024個機器使用。
  • 序列號：12 bit長度，可以在4096個數字中隨機取值，從而避免單個機器在1 ms內生成重複的序列號。

但是在實際原始碼實現中，Snowflake把10 bit的可配置的機器ID拆分為5 bit的Worker ID（這個可以理解為原來的機器ID）和5 bit的Data Center ID（資料中心ID），詳情見IdWorker.scala：

也就是說，支援配置最多32個機器ID和最多32個資料中心ID：

由於演算法是Scala語言編寫，是依賴於JVM的語言，返回的ID值為Long型別，也就是64 bit的整數，原來的演算法生成序列中只使用了63 bit的長度，要返回的是無符號數，所以在高位補一個0（佔用1 bit），那麼加起來整個ID的長度就是64 bit：

其中：

  • 41 bit毫秒級別時間戳的取值範圍是：[0, 2^41 - 1] => 0 ~ 2199023255551，一共2199023255552個數字。
  • 5 bit機器ID的取值範圍是：[0, 2^5 - 1] => 0 ~ 31，一共32個數字。
  • 5 bit資料中心ID的取值範圍是：[0, 2^5 - 1] => 0 ~ 31，一共32個數字。
  • 12 bit序列號的取值範圍是：[0, 2^12 - 1] => 0 ~ 4095，一共4096個數字。

那麼理論上可以生成2199023255552 * 32 * 32 * 4096個完全不同的ID值。

Snowflake演算法還有一個明顯的特徵：依賴於系統時鐘。41 bit長度毫秒級別的時間來源於系統時間戳，所以必須保證系統時間是向前遞進，不能發生時鐘回撥（通說來說就是不能在同一個時刻產生多個相同的時間戳或者產生了過去的時間戳）。一旦發生時鐘回撥，Snowflake會拒絕生成下一個ID。

位運算知識補充

Snowflake演算法中使用了大量的位運算。由於整數的補碼才是在計算機中的儲存形式，Java或者Scala中的整型都使用補碼錶示，這裡稍微提一下原碼和補碼的知識。

  • 原碼用於閱讀，補碼用於計算。
  • 正數的補碼與其原碼相同。
  • 負數的補碼是除最高位其他所有位取反，然後加1（反碼加1），而負數的補碼還原為原碼也是使用這個方式。
  • +0的原碼是0000 0000，而-0的原碼是1000 0000，補碼只有一個0值，用0000 0000表示，這一點很重要，補碼的0沒有二義性。

簡單來看就是這樣：

* [+ 11] 原碼 = [0000 1011] 補碼 = [0000 1011]
* [- 11] 原碼 = [1000 1011] 補碼 = [1111 0101]

* [- 11]的補碼計算過程： 
        原碼                  1000 1011
        除了最高位其他位取反   1111 0100
        加1                   1111 0101  （補碼）

使用原碼、反碼在計算的時候得到的不一定是準確的值，而使用補碼的時候計算結果才是正確的，記住這個結論即可，這裡不在舉例。由於Snowflake的ID生成方案中，除了最高位，其他四個部分都是無符號整數，所以四個部分的整數使用補碼進行位運算的效率會比較高，也只有這樣才能滿足Snowflake高效能設計的初衷。Snowflake演算法中使用了幾種位運算：異或（^）、按位與（&）、按位或（|）和帶符號左移（<<）。

異或

異或的運算規則是：0^0=0 0^1=1 1^0=1 1^1=0，也就是位不同則結果為1，位相同則結果為0。主要作用是：

  • 特定位翻轉，也就是一個數和N個位都為1的數進行異或操作，這對應的N個位都會翻轉，例如0100 & 1111，結果就是1011。
  • 與0項異或，則結果和原來的值一致。
  • 兩數的值互動：a=a^b b=b^a a=a^b，這三個操作完成之後，a和b的值完成交換。

這裡推演一下最後一條：

* [+ 11] 原碼 = [0000 1011] 補碼 = [0000 1011] a
* [- 11] 原碼 = [1000 1011] 補碼 = [1111 0101] b

a=a^b          0000 1011
               1111 0101
               ---------^
               1111 1110
b=b^a          1111 0101
               ---------^
               0000 1011  （十進位制數：11） b
a=a^b          1111 1110
               ---------^
               1111 0101  （十進位制數：-11） a

按位與

按位與的運算規則是：0^0=0 0^1=0 1^0=0 1^1=1，只有對應的位都為1的時候計算結果才是1，其他情況的計算結果都是0。主要作用是：

  • 清零，如果想把一個數清零，那麼和所有位為0的數進行按位與即可。
  • 取一個數中的指定位，例如要取X中的低4位，只需要和zzzz...1111進行按位與即可，例如取1111 0110的低4位，則11110110 & 00001111即可得到00000110。

按位或

按位與的運算規則是：0^0=0 0^1=1 1^0=1 1^1=1，只要有其中一個位存在1則計算結果是1，只有兩個位同時為0的情況下計算結果才是0。主要作用是：

  • 對一個數的部分位賦值為1，只需要和對應位全為0的數做按位或操作就行，例如1011 0000如果低4位想全部賦值為1，那麼10110000 | 00001111即可得到1011 1111。

帶符號左移

帶符號左移的運算子是<<，一般格式是：M << n。作用如下：

  • M的二進位制數（補碼）向左移動n位。
  • 左邊（高位）移出部分直接捨棄，右邊（低位）移入部分全部補0。
  • 移位結果：相當於M的值乘以2的n次方，並且0、正、負數通用。
  • 移動的位數超過了該型別的最大位數，那麼編譯器會對移動的位數取模，例如int移位33位，實際上只移動了33 % 2 = 1位。

推演過程如下（假設n = 2）：

* [+ 11] 原碼 = [0000 1011] 補碼 = [0000 1011]
* [- 11] 原碼 = [1000 1011] 補碼 = [1111 0101]

* [+ 11 << 2]的計算過程
      補碼          0000 1011
      左移2位     0000 1011  
      舍高補低      0010 1100
      十進位制數    2^2 + 2^3 + 2^5 = 44

* [- 11 << 2]的計算過程
      補碼          1111 0101
      左移2位     1111 0101  
      舍高補低      1101 0100 
      原碼          1010 1100 （補碼除最高位其他所有位取反再加1）
      十進位制數    - (2^2 + 2^3 + 2^5) = -44

可以寫個main方法驗證一下：

public static void main(String[] args) {
      System.out.println(-11 << 2); // -44
      System.out.println(11 << 2);  // 44
}

組合技巧

利用上面提到的三個位運算子，相互組合可以實現一些高效的計算方案。

計算n個bit能表示的最大數值：

Snowflake演算法中有這樣的程式碼：

// 機器ID的位長度
private val workerIdBits = 5L;
// 最大機器ID -> 31
private val maxWorkerId = -1L ^ (-1L << workerIdBits);

這裡的運算元是-1L ^ (-1L << 5L)，整理運算子的順序，再使用64 bit的二進位制數推演計算過程如下：

* [-1] 的補碼         11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111
  左移5位             11111111 11111111 11111111 11111111 11111111 11111111 11111111 11100000
  [-1] 的補碼         11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111
  異或                ----------------------------------------------------------------------- ^ 
  結果的補碼          00000000 00000000 00000000 00000000 00000000 00000000 00000000 00011111  （十進位制數 2^0 + 2^1 + 2^2 + 2^3 + 2^4 = 31）

這樣就能計算出5 bit能表示的最大數值n，n為整數並且0 <= n <= 31，即0、1、2、3...31。Worker ID和Data Center ID部分的最大值就是使用這種組合運算得出的。

用固定位的最大值作為Mask避免溢位：

Snowflake演算法中有這樣的程式碼：

var sequence = 0L
......
private val sequenceBits = 12L
// 這裡得到的是sequence的最大值4095
private val sequenceMask = -1L ^ (-1L << sequenceBits)
......
sequence = (sequence + 1) & sequenceMask

最後這個運算元其實就是sequence = (sequence + 1) & 4095，假設sequence當前值為4095，推演一下計算過程：

* [4095] 的補碼                 00000000 00000000 00000000 00000000 00000000 00000000 00000111 11111111
  [sequence + 1] 的補碼         00000000 00000000 00000000 00000000 00000000 00000000 00001000 00000000
  按位與                        ----------------------------------------------------------------------- &
  計算結果                      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000  （十進位制數：0）

可以編寫一個main方法驗證一下：

public static void main(String[] args) {
    int mask = 4095;
    System.out.println(0 & mask); // 0
    System.out.println(1 & mask); // 1
    System.out.println(2 & mask); // 2
    System.out.println(4095 & mask); // 4095
    System.out.println(4096 & mask); // 0
    System.out.println(4097 & mask); // 1
}

也就是x = (x + 1) & (-1L ^ (-1L << N))能保證最終得到的x值不會超過N，這是利用了按位與中的"取指定位"的特性。

Snowflake演算法實現原始碼分析

Snowflake雖然用Scala語言編寫，語法其實和Java差不多，當成Java程式碼這樣閱讀就行，下面閱讀程式碼的時候會跳過一些日誌記錄和度量統計的邏輯。先看IdWorker.scala的屬性值：

// 定義基準紀元值，這個值是北京時間2010-11-04 09:42:54，估計就是2010年初版提交程式碼時候定義的一個時間戳
val twepoch = 1288834974657L

// 初始化序列號為0
var sequence = 0L //TODO after 2.8 make this a constructor param with a default of 0

// 機器ID的最大位長度為5
private val workerIdBits = 5L

// 資料中心ID的最大位長度為5
private val datacenterIdBits = 5L

// 最大的機器ID值，十進位制數為為31
private val maxWorkerId = -1L ^ (-1L << workerIdBits)

// 最大的資料中心ID值，十進位制數為為31
private val maxDatacenterId = -1L ^ (-1L << datacenterIdBits)

// 序列號的最大位長度為12
private val sequenceBits = 12L

// 機器ID需要左移的位數12
private val workerIdShift = sequenceBits

// 資料中心ID需要左移的位數 = 12 + 5
private val datacenterIdShift = sequenceBits + workerIdBits

// 時間戳需要左移的位數 = 12 + 5 + 5
private val timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits

// 序列號的掩碼，十進位制數為4095
private val sequenceMask = -1L ^ (-1L << sequenceBits)

// 初始化上一個時間戳快照值為-1
private var lastTimestamp = -1L

// 下面的程式碼塊為引數校驗和初始化日誌列印，這裡不做分析
if (workerId > maxWorkerId || workerId < 0) {
exceptionCounter.incr(1)
throw new IllegalArgumentException("worker Id can't be greater than %d or less than 0".format(maxWorkerId))
}

if (datacenterId > maxDatacenterId || datacenterId < 0) {
exceptionCounter.incr(1)
throw new IllegalArgumentException("datacenter Id can't be greater than %d or less than 0".format(maxDatacenterId))
}

log.info("worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d",
timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId)

接著看演算法的核心程式碼邏輯：

// 同步方法，其實就是protected synchronized long nextId(){ ...... }
protected[snowflake] def nextId(): Long = synchronized {
    // 獲取系統時間戳（毫秒）
    var timestamp = timeGen()
    // 高併發場景，同一毫秒內生成多個ID
    if (lastTimestamp == timestamp) {
        // 確保sequence + 1之後不會溢位，最大值為4095，其實也就是保證1毫秒內最多生成4096個ID值
        sequence = (sequence + 1) & sequenceMask
        // 如果sequence溢位則變為0，說明1毫秒內併發生成的ID數量超過了4096個，這個時候同1毫秒的第4097個生成的ID必須等待下一毫秒
        if (sequence == 0) {
            // 死迴圈等待下一個毫秒值，直到比lastTimestamp大
            timestamp = tilNextMillis(lastTimestamp)
        }
    } else {
        // 低併發場景，不同毫秒中生成ID
        // 不同毫秒的情況下，由於外層方法保證了timestamp大於或者小於lastTimestamp，而小於的情況是發生了時鐘回撥，下面會丟擲異常，所以不用考慮
        // 也就是隻需要考慮一種情況：timestamp > lastTimestamp，也就是當前生成的ID所在的毫秒數比上一個ID大
        // 所以如果時間戳部分增大，可以確定整數值一定變大，所以序列號其實可以不用計算，這裡直接賦值為0
        sequence = 0
    }
    // 獲取到的時間戳比上一個儲存的時間戳小，說明時鐘回撥，這種情況下直接丟擲異常，拒絕生成ID
    // 個人認為，這個方法應該可以提前到var timestamp = timeGen()這段程式碼之後
    if (timestamp < lastTimestamp) {
      exceptionCounter.incr(1)
      log.error("clock is moving backwards.  Rejecting requests until %d.", lastTimestamp);
      throw new InvalidSystemClock("Clock moved backwards.  Refusing to generate id for %d milliseconds".format(lastTimestamp - timestamp));
    }
    // lastTimestamp儲存當前時間戳，作為方法下次被呼叫的上一個時間戳的快照
    lastTimestamp = timestamp
    // 度量統計，生成的ID計數器加1
    genCounter.incr()
    // X = (系統時間戳 - 自定義的紀元值) 然後左移22位
    // Y = (資料中心ID左移17位)
    // Z = (機器ID左移12位)
    // 最後ID = X | Y | Z | 計算出來的序列號sequence
    ((timestamp - twepoch) << timestampLeftShift) |
      (datacenterId << datacenterIdShift) |
      (workerId << workerIdShift) | 
      sequence
}

// 輔助方法：獲取系統當前的時間戳（毫秒）
protected def timeGen(): Long = System.currentTimeMillis()

// 輔助方法：獲取系統當前的時間戳（毫秒），用死迴圈保證比傳入的lastTimestamp大，也就是獲取下一個比lastTimestamp大的毫秒數
protected def tilNextMillis(lastTimestamp: Long): Long = {
    var timestamp = timeGen()
    while (timestamp <= lastTimestamp) {
      timestamp = timeGen()
    }
    timestamp
}

最後一段邏輯的位操作比較多，但是如果熟練使用位運算操作符，其實邏輯並不複雜，這裡可以畫個圖推演一下：

四個部分的整數完成左移之後，由於空缺的低位都會補充了0，基於按位或的特性，所有低位只要存在1，那麼對應的位就會填充為1，由於四個部分的位不會越界分配，所以這裡的本質就是：四個部分左移完畢後最終的數字進行加法計算。

Snowflake演算法改良

Snowflake演算法有幾個比較大的問題：

  • 低併發場景會產生連續偶數，原因是低併發場景系統時鐘總是走到下一個毫秒值，導致序列號重置為0。
  • 依賴系統時鐘，時鐘回撥會拒絕生成新的ID（直接丟擲異常）。
  • Woker ID和Data Center ID的管理比較麻煩，特別是同一個服務的不同叢集節點需要保證每個節點的Woker ID和Data Center ID組合唯一。

這三個問題美團開源的Leaf提供瞭解決思路，下圖擷取自com.sankuai.inf.leaf.snowflake.SnowflakeIDGenImpl：

對應的解決思路是（不進行深入的原始碼分析，有興趣可以閱讀以下Leaf的原始碼）：

  • 序列號生成新增隨機源，會稍微減少同一個毫秒內能產生的最大ID數量。
  • 時鐘回撥則進行一定期限的等待。
  • 使用Zookeeper快取和管理Woker ID和Data Center ID。

Woker ID和Data Center ID的配置是極其重要的，對於同一個服務（例如支付服務）叢集的多個節點，必須配置不同的機器ID和資料中心ID或者同樣的資料中心ID和不同的機器ID（簡單說就是確保Woker ID和Data Center ID的組合全域性唯一），否則在高併發的場景下，在系統時鐘一致的情況下，很容易在多個節點產生相同的ID值，所以一般的部署架構如下：

管理這兩個ID的方式有很多種，或者像Leaf這樣的開源框架引入分散式快取進行管理，再如筆者所在的創業小團隊生產服務比較少，直接把Woker ID和Data Center ID硬編碼在服務啟動指令碼中，然後把所有服務使用的Woker ID和Data Center ID統一登記在團隊內部知識庫中。

自實現簡化版Snowflake

如果完全不考慮效能的話，也不考慮時鐘回撥、序列號生成等等問題，其實可以把Snowflake的位運算和異常處理部分全部去掉，使用Long.toBinaryString()方法結合字串按照Snowflake演算法思路拼接出64 bit的二進位制數，再通過Long.parseLong()方法轉化為Long型別。編寫一個main方法如下：

public class Main {

    private static final String HIGH = "0";

    /**
     * 2020-08-01 00:00:00
     */
    private static final long EPOCH = 1596211200000L;

    public static void main(String[] args) {
        long workerId = 1L;
        long dataCenterId = 1L;
        long seq = 4095;
        String timestampString = leftPadding(Long.toBinaryString(System.currentTimeMillis() - EPOCH), 41);
        String workerIdString = leftPadding(Long.toBinaryString(workerId), 5);
        String dataCenterIdString = leftPadding(Long.toBinaryString(dataCenterId), 5);
        String seqString = leftPadding(Long.toBinaryString(seq), 12);
        String value = HIGH + timestampString + workerIdString + dataCenterIdString + seqString;
        long num = Long.parseLong(value, 2);
        System.out.println(num);   // 某個時刻輸出為3125927076831231
    }

    private static String leftPadding(String value, int maxLength) {
        int diff = maxLength - value.length();
        StringBuilder builder = new StringBuilder();
        for (int i = 0; i < diff; i++) {
            builder.append("0");
        }
        builder.append(value);
        return builder.toString();
    }
}

然後把程式碼規範一下，編寫出一個簡版Snowflake演算法實現的工程化程式碼：

// 主鍵生成器介面
public interface PrimaryKeyGenerator {

    long generate();
}

// 簡易Snowflake實現
public class SimpleSnowflake implements PrimaryKeyGenerator {

    private static final String HIGH = "0";
    private static final long MAX_WORKER_ID = 31;
    private static final long MIN_WORKER_ID = 0;

    private static final long MAX_DC_ID = 31;
    private static final long MIN_DC_ID = 0;

    private static final long MAX_SEQUENCE = 4095;

    /**
     * 機器ID
     */
    private final long workerId;

    /**
     * 資料中心ID
     */
    private final long dataCenterId;

    /**
     * 基準紀元值
     */
    private final long epoch;

    private long sequence = 0L;
    private long lastTimestamp = -1L;

    public SimpleSnowflake(long workerId, long dataCenterId, long epoch) {
        this.workerId = workerId;
        this.dataCenterId = dataCenterId;
        this.epoch = epoch;
        checkArgs();
    }

    private void checkArgs() {
        if (!(MIN_WORKER_ID <= workerId && workerId <= MAX_WORKER_ID)) {
            throw new IllegalArgumentException("Worker id must be in [0,31]");
        }
        if (!(MIN_DC_ID <= dataCenterId && dataCenterId <= MAX_DC_ID)) {
            throw new IllegalArgumentException("Data center id must be in [0,31]");
        }
    }

    @Override
    public synchronized long generate() {
        long timestamp = System.currentTimeMillis();
        // 時鐘回撥
        if (timestamp < lastTimestamp) {
            throw new IllegalStateException("Clock moved backwards");
        }
        // 同一毫秒內併發
        if (lastTimestamp == timestamp) {
            sequence = sequence + 1;
            if (sequence == MAX_SEQUENCE) {
                timestamp = untilNextMillis(lastTimestamp);
                sequence = 0L;
            }
        } else {
            // 下一毫秒重置sequence為0
            sequence = 0L;
        }
        lastTimestamp = timestamp;
        // 41位時間戳字串，不夠位數左邊補"0"
        String timestampString = leftPadding(Long.toBinaryString(timestamp - epoch), 41);
        // 5位機器ID字串，不夠位數左邊補"0"
        String workerIdString = leftPadding(Long.toBinaryString(workerId), 5);
        // 5位資料中心ID字串，不夠位數左邊補"0"
        String dataCenterIdString = leftPadding(Long.toBinaryString(dataCenterId), 5);
        // 12位序列號字串，不夠位數左邊補"0"
        String seqString = leftPadding(Long.toBinaryString(sequence), 12);
        String value = HIGH + timestampString + workerIdString + dataCenterIdString + seqString;
        return Long.parseLong(value, 2);
    }

    private long untilNextMillis(long lastTimestamp) {
        long timestamp;
        do {
            timestamp = System.currentTimeMillis();
        } while (timestamp <= lastTimestamp);
        return timestamp;
    }

    private static String leftPadding(String value, int maxLength) {
        int diff = maxLength - value.length();
        StringBuilder builder = new StringBuilder();
        for (int i = 0; i < diff; i++) {
            builder.append("0");
        }
        builder.append(value);
        return builder.toString();
    }

    public static void main(String[] args) {
        long epoch = LocalDateTime.of(1970, 1, 1, 0, 0, 0, 0)
                .toInstant(ZoneOffset.of("+8")).toEpochMilli();
        PrimaryKeyGenerator generator = new SimpleSnowflake(1L, 1L, epoch);
        for (int i = 0; i < 5; i++) {
            System.out.println(String.format("第%s個生成的ID: %d", i + 1, generator.generate()));
        }
    }
}

// 某個時刻輸出如下
第1個生成的ID: 6698247966366502912
第2個生成的ID: 6698248027448152064
第3個生成的ID: 6698248032162549760
第4個生成的ID: 6698248033076908032
第5個生成的ID: 6698248033827688448

通過字串拼接的寫法雖然執行效率低，但是可讀性會比較高，工程化處理後的程式碼可以在例項化時候直接指定Worker ID和Data Center ID等值，並且這個簡易的Snowflake實現沒有第三方庫依賴，拷貝下來可以直接執行。上面的方法使用字串拼接看起來比較低端，其實最後那部分的按位或，可以完全轉化為加法：

public class Main {
    
    /**
     * 2020-08-01 00:00:00
     */
    private static final long EPOCH = 1596211200000L;

    public static void main(String[] args) {
        long workerId = 1L;
        long dataCenterId = 1L;
        long seq = 4095;
        long timestampDiff = System.currentTimeMillis() - EPOCH;
        long num = (long) (timestampDiff * Math.pow(2, 22)) + (long) (dataCenterId * Math.pow(2, 17)) + (long) (workerId * Math.pow(2, 12)) + seq;
        System.out.println(num);   // 某個時刻輸出為3248473482862591
    }
}

這樣看起來整個演算法都變得簡單，不過這裡涉及到指數運算和加法運算，效率會比較低。

小結

Snowflake演算法是以高效能為核心目標的演算法，基於這一點目的巧妙地大量使用位運算，這篇文章已經把Snowflake中應用到的位運算和具體原始碼實現徹底分析清楚。最後，基於Twitter官方的Snowflake演算法原始碼，修訂出了一版Java實現版本，並且應用前面提到的改良方式，修復了低併發場景下只產生偶數的問題，並且已經應用於生產環境一段時間，程式碼倉庫如下（程式碼沒有任何第三方庫依賴，拷貝出來就直接可用）：

  • Github：https://github.com/zjcscut/framework-mesh/tree/master/java-snowflake

參考資料：

（本文完 c-3-d e-a-20200809 封面圖來源於國漫《靈籠》）

相關文章