一文詳解分散式 ID

前言

分散式系統中，我們經常需要對資料、訊息等進行唯一標識，這個唯一標識就是分散式 ID，那麼我們如何設計它呢？本文將詳細講述分散式 ID 及其生成方案。

---

一、為什麼需要分散式 ID

目前大部分的系統都已是分散式系統，所以在這種場景的業務開發中，經常會需要唯一 ID 對資料進行標識，比如使用者身份標識、訊息標識等等。

並且在資料量達到一定規模後，大部分的系統也需要進行分庫分表，這種場景下單庫的自增 ID 已達不到我們的預期。所以我們需要分散式 ID 來對各種場景的資料進行唯一標識。

二、分散式 ID 的特性

主要特性：

• 全域性唯一：分散式 ID 最基本要求，必須全域性唯一。
• 高可用：高併發下要保證 ID 的生成效率，避免影響系統。
• 易用性：使用簡單，可快速接入。

除此之外根據不同場景還有：

• 有序性：資料庫場景下的主鍵 ID，有序性可便於資料寫入和排序。
• 安全性：無規則 ID，一般用於避免業務資訊洩露場景，如訂單量。

二、分散式 ID 常見生成方案

1. UUID

UUID（Universally Unique Identifier），即通用唯一識別碼。UUID 的目的是讓分散式系統中的所有元素都能有唯一的識別資訊。

UUID 是由128位二進位制陣列成，通常表示為32個十六進位制字元，形如：

550e8400-e29b-41d4-a716-446655440000

這個字串由五個部分組成，以連字元-分隔開，具體如下：

部分	大小	說明
時間戳	32 bits	UUID的前32位表示當前的時間戳。
時鐘序列和隨機數	16 bits	用於保證在同一時刻生成的UUID的唯一性。
變體標識	4 bits	標識 UUID 的變體，通常為固定值，表示是由 RFC 4122 定義。
版本號	4 bits	標識UUID的版本，常見版本有1、3、4和5
節點	48 bits	在版本 1 中，這部分包含生成 UUID 的計算機的唯一標識。

主要的 UUID 版本及其生成規則：

版本	場景	生成規則
版本 1	基於時間和節點	由當前的時間戳和節點資訊生成。包括時間戳、時鐘序列、節點標識。
版本 2	基於DCE安全識別符號	類似版本 1，但在時間戳部分包含 POSIX UID/GID 資訊。
版本 3	基於名字和雜湊值（MD5 版）	由名稱空間和名字的MD5雜湊生成。
版本 4	完全隨機生成	透過隨機或偽隨機生成128位數字。
版本 5	基於名字和雜湊值（SHA-1 版）	透過隨機或偽隨機生成128位數字。

Java中 UUID 對版本 4 進行了實現：

public static void main (String[] args) {
    // 預設版本 4
    System.out.println(UUID.randomUUID());

    // 版本 3，由名稱空間和名字的MD5雜湊生成，相同名稱空間結果相同
    // 如下，"fuxing"返回的UUID一直為8b9b6bc3-90c8-37ef-bbef-0ed0c552718f
    System.out.println(UUID.nameUUIDFromBytes("fuxing".getBytes()));
}

優點： 本地生成，沒有網路消耗，效能非常高。

缺點：

• 佔用空間大，32 個字串，128 位。
• 不安全：版本 1 可能會造成 mac 地址洩露。
• 無序，非自增。
• 機器時間不對，可能造成 UUID 重複。

2. 資料庫自增 ID

實現簡單，解釋透過資料庫表中的主鍵 ID 自增來生成唯一標識。如下，維護一個 MySQL 表來生成 ID。

CREATE TABLE `unique_id` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `value` char(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

當需要生成分散式 ID 時，向表中插入資料並返回主鍵 ID，這裡 value 無含義，只是為了佔位，方便插入資料。

優點： 實現簡單，基本滿足業務需求，且天然有序。

缺點：

• 資料庫自身的單點故障和資料一致性問題。
• 不安全，比如可根據自增來判斷訂單量。
• 高併發場景可能會受限於資料庫瓶頸。

那麼有沒有辦法解決資料庫自增 ID 的缺點呢？

透過水平拆分的方案，將表設定到不同的資料庫中，設定不同的起始值和步長，這樣可以有效的生成叢集中的唯一 ID，也大大降低 ID 生成資料庫操作的負載，示例如下。

unique_id_1配置：

set @@auto_increment_offset = 1;     -- 起始值
set @@auto_increment_increment = 2;  -- 步長

unique_id_2配置：

set @@auto_increment_offset = 2;     -- 起始值
set @@auto_increment_increment = 2;  -- 步長

這個還是需要根據自己的業務需求來，水平擴充套件的叢集數量要符合自己的資料量，因為當設定的叢集數量不足以滿足高併發時，再次進行擴容叢集會很麻煩。多臺機器的起始值和步長都需要重新配置。

3. 資料庫號段模式

號段模式是當下分散式 ID 生成器的主流實現方式之一，比如美團 Leaf-segment、滴滴 Tinyid、微信序列號等都使用的該方案，下面的大廠中介軟體中會展開說明。

號段模式也是基於資料庫的自增 ID，資料庫自增 ID 是一次性獲取一個分散式 ID，號段模式可以理解成從資料庫批次獲取 ID，然後將 ID 快取在本地，以此來提高業務獲取 ID 的效率。

例如，每次從資料庫獲取 ID 時，獲取一個號段，如(1,1000]，這個範圍表示 1000 個 ID，業務應用在請求獲取 ID 時，只需要在本地從 1 開始自增並返回，而不用每次去請求資料庫，一直到本地自增到 1000 時，才去資料庫重新獲取新的號段，後續流程迴圈往復。

表結構可進行如下設計：

CREATE TABLE `id_generator` (
  `id` int(10) NOT NULL,
  `max_id` bigint(20) NOT NULL COMMENT '當前最大id',
  `step` int(10) NOT NULL COMMENT '號段的步長',
  `version` int(20) NOT NULL COMMENT '版本號',
  `biz_type` int(20) NOT NULL COMMENT '業務場景',
   PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

其中max_id和step用於獲取批次的 ID，version是一個樂觀鎖，保證併發時資料的正確性。

比如，我們新增一條表資料如下。

id	max_id	step	version	biz_type
1	100	1000	0	001

然後我們可以使用該號段批次生成的 ID，當max_id = 1000，則執行 update 操作生成新的號段。新的號段的 SQL。

UPDATE 
id_generator 
SET 
max_id = #{max_id+ step}, 
version = version + 1 
WHERE 
version = #{version} AND biz_type = 001;

優點： ID 有序遞增、儲存消耗空間小。

缺點：

• 資料庫自身的單點故障和資料一致性問題。
• 不安全，比如可根據自增來判斷訂單量。
• 高併發場景可能會受限於資料庫瓶頸。

缺點同樣可以透過叢集的方式進行最佳化，也可以如Tinyid 採用雙快取進行最佳化，下面的大廠中介軟體中會展開說明。

4. 基於Redis

當使用資料庫來生成 ID 效能不夠的時候，可以嘗試使用 Redis 來生成 ID。原理則是利用 Redis 的原子操作 INCR 和 INCRBY 來實現。

命令示例：

命令	說明	示例
INCR	讓一個整形的key自增1	redis> SET mykey "10" "OK" redis> INCR mykey (integer) 11
INCRBY	讓一個整形的key自增並指定步長	redis> SET mykey "10" "OK" redis> INCRBY mykey 5 (integer) 15

優點： 不依賴於資料庫，使用靈活，支援高併發。

缺點：

• 系統須引入 Redis 資料庫。
• 不安全，比如可根據自增來判斷訂單量。
• Redis 出現單點故障問題，可能會丟資料導致 ID 重複。

5. 雪花演算法

雪花演算法（Snowflake）是 twitter 公司內部分散式專案採用的 ID 生成演算法。結果是一個 long 型的 ID。Snowflake 演算法將 64bit 劃分為多段，分開來標識機器、時間等資訊，具體組成結構如下圖所示：

結構說明：

結構	大小	說明
符號位	1 bit	0 表示正數，1 表示負數。
時間戳	41 bits	儲存的是當前時間戳 - 開始時間戳，最長 69 年。
機器位	10 bits	前 5位 datacenterId，後 5 位 workerId ，最多表示 1024 臺。
序列號	12 bits	毫秒內的流水號，意味著每個節點在每毫秒可以產生 4096 個 ID。

優點：
穩定性高，不依賴於資料庫等第三方系統。
使用靈活方便，可以根據業務需求的特性來調整演算法中的 bit 位。
單機上 ID 單調自增，毫秒數在高位，自增序列在低位，整體上按照時間自增排序。

缺點：

• 強依賴機器時鐘，如果機器上時鐘回撥，可能導致發號重複或者服務處於不可用狀態。
• ID 可能不是全域性遞增，雖然 ID 在單機上是遞增的。
• Redis 出現單點故障問題，可能會丟資料導致 ID 重複。

演算法實現（Java）：

package util;
 
import java.util.Date;
 
/**
 * @ClassName: SnowFlakeUtil
 * @Author: jiaoxian
 * @Date: 2022/4/24 16:34
 * @Description:
 */
public class SnowFlakeUtil {
 
    private static SnowFlakeUtil snowFlakeUtil;
    static {
        snowFlakeUtil = new SnowFlakeUtil();
    }
 
    // 初始時間戳(紀年)，可用雪花演算法服務上線時間戳的值
    // 1650789964886：2022-04-24 16:45:59
    private static final long INIT_EPOCH = 1650789964886L;
 
    // 時間位取&
    private static final long TIME_BIT = 0b1111111111111111111111111111111111111111110000000000000000000000L;
 
    // 記錄最後使用的毫秒時間戳，主要用於判斷是否同一毫秒，以及用於伺服器時鐘回撥判斷
    private long lastTimeMillis = -1L;
 
    // dataCenterId佔用的位數
    private static final long DATA_CENTER_ID_BITS = 5L;
 
    // dataCenterId佔用5個位元位，最大值31
    // 0000000000000000000000000000000000000000000000000000000000011111
    private static final long MAX_DATA_CENTER_ID = ~(-1L << DATA_CENTER_ID_BITS);
 
    // dataCenterId
    private long dataCenterId;
 
    // workId佔用的位數
    private static final long WORKER_ID_BITS = 5L;
 
    // workId佔用5個位元位，最大值31
    // 0000000000000000000000000000000000000000000000000000000000011111
    private static final long MAX_WORKER_ID = ~(-1L << WORKER_ID_BITS);
 
    // workId
    private long workerId;
 
    // 最後12位，代表每毫秒內可產生最大序列號，即 2^12 - 1 = 4095
    private static final long SEQUENCE_BITS = 12L;
 
    // 掩碼（最低12位為1，高位都為0），主要用於與自增後的序列號進行位與，如果值為0，則代表自增後的序列號超過了4095
    // 0000000000000000000000000000000000000000000000000000111111111111
    private static final long SEQUENCE_MASK = ~(-1L << SEQUENCE_BITS);
 
    // 同一毫秒內的最新序號，最大值可為 2^12 - 1 = 4095
    private long sequence;
 
    // workId位需要左移的位數 12
    private static final long WORK_ID_SHIFT = SEQUENCE_BITS;
 
    // dataCenterId位需要左移的位數 12+5
    private static final long DATA_CENTER_ID_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS;
 
    // 時間戳需要左移的位數 12+5+5
    private static final long TIMESTAMP_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS + DATA_CENTER_ID_BITS;
 
    /**
     * 無參構造
     */
    public SnowFlakeUtil() {
        this(1, 1);
    }
 
    /**
     * 有參構造
     * @param dataCenterId
     * @param workerId
     */
    public SnowFlakeUtil(long dataCenterId, long workerId) {
        // 檢查dataCenterId的合法值
        if (dataCenterId < 0 || dataCenterId > MAX_DATA_CENTER_ID) {
            throw new IllegalArgumentException(
                    String.format("dataCenterId 值必須大於 0 並且小於 %d", MAX_DATA_CENTER_ID));
        }
        // 檢查workId的合法值
        if (workerId < 0 || workerId > MAX_WORKER_ID) {
            throw new IllegalArgumentException(String.format("workId 值必須大於 0 並且小於 %d", MAX_WORKER_ID));
        }
        this.workerId = workerId;
        this.dataCenterId = dataCenterId;
    }
 
    /**
     * 獲取唯一ID
     * @return
     */
    public static Long getSnowFlakeId() {
        return snowFlakeUtil.nextId();
    }
 
    /**
     * 透過雪花演算法生成下一個id，注意這裡使用synchronized同步
     * @return 唯一id
     */
    public synchronized long nextId() {
        long currentTimeMillis = System.currentTimeMillis();
        System.out.println(currentTimeMillis);
        // 當前時間小於上一次生成id使用的時間，可能出現伺服器時鐘回撥問題
        if (currentTimeMillis < lastTimeMillis) {
            throw new RuntimeException(
                    String.format("可能出現伺服器時鐘回撥問題，請檢查伺服器時間。當前伺服器時間戳：%d，上一次使用時間戳：%d", currentTimeMillis,
                            lastTimeMillis));
        }
        if (currentTimeMillis == lastTimeMillis) {
            // 還是在同一毫秒內，則將序列號遞增1，序列號最大值為4095
            // 序列號的最大值是4095，使用掩碼（最低12位為1，高位都為0）進行位與執行後如果值為0，則自增後的序列號超過了4095
            // 那麼就使用新的時間戳
            sequence = (sequence + 1) & SEQUENCE_MASK;
            if (sequence == 0) {
                currentTimeMillis = getNextMillis(lastTimeMillis);
            }
        } else { // 不在同一毫秒內，則序列號重新從0開始，序列號最大值為4095
            sequence = 0;
        }
        // 記錄最後一次使用的毫秒時間戳
        lastTimeMillis = currentTimeMillis;
        // 核心演算法，將不同部分的數值移動到指定的位置，然後進行或執行
        // <<：左移運算子, 1 << 2 即將二進位制的 1 擴大 2^2 倍
        // |：位或運算子, 是把某兩個數中, 只要其中一個的某一位為1, 則結果的該位就為1
        // 優先順序：<< > |
        return
                // 時間戳部分
                ((currentTimeMillis - INIT_EPOCH) << TIMESTAMP_SHIFT)
                // 資料中心部分
                | (dataCenterId << DATA_CENTER_ID_SHIFT)
                // 機器表示部分
                | (workerId << WORK_ID_SHIFT)
                // 序列號部分
                | sequence;
    }
 
    /**
     * 獲取指定時間戳的接下來的時間戳，也可以說是下一毫秒
     * @param lastTimeMillis 指定毫秒時間戳
     * @return 時間戳
     */
    private long getNextMillis(long lastTimeMillis) {
        long currentTimeMillis = System.currentTimeMillis();
        while (currentTimeMillis <= lastTimeMillis) {
            currentTimeMillis = System.currentTimeMillis();
        }
        return currentTimeMillis;
    }
 
    /**
     * 獲取隨機字串,length=13
     * @return
     */
    public static String getRandomStr() {
        return Long.toString(getSnowFlakeId(), Character.MAX_RADIX);
    }
 
    /**
     * 從ID中獲取時間
     * @param id 由此類生成的ID
     * @return
     */
    public static Date getTimeBySnowFlakeId(long id) {
        return new Date(((TIME_BIT & id) >> 22) + INIT_EPOCH);
    }
 
    public static void main(String[] args) {
        SnowFlakeUtil snowFlakeUtil = new SnowFlakeUtil();
        long id = snowFlakeUtil.nextId();
        System.out.println(id);
        Date date = SnowFlakeUtil.getTimeBySnowFlakeId(id);
        System.out.println(date);
        long time = date.getTime();
        System.out.println(time);
        System.out.println(getRandomStr());
 
    }
 
}

四、大廠中介軟體

1. 美團 Leaf

Leaf 的官方文件，簡介和特性可訪問了解，這裡我將對 Leaf 的兩種方案，Leaf segment 和 Leaf-snowflake 進行。

1.1. Leaf segment

基於資料庫號段模式的 ID 生成方案，上面我們介紹到普通的號段模式有一些缺點：

• 資料庫自身的單點故障和資料一致性問題。
• 不安全，比如可根據自增來判斷訂單量。
• 高併發場景可能會受限於資料庫瓶頸。

那麼 Leaf 是如何做的呢？Leaf 採用了預分發的方式生成ID，也就是在 DB 之上掛 n 個 Leaf Server，每個Server啟動時，都會去 DB 拿固定長度的 ID List。

這樣就做到了完全基於分散式的架構，同時因為ID是由記憶體分發，所以也可以做到很高效，處理流程圖如下：

其中：

• Leaf Server 1：從 DB 載入號段[1，1000]。
• Leaf Server 2：從 DB 載入號段[1001，2000]。
• Leaf Server 3：從 DB 載入號段[2001，3000]。

使用者透過輪詢的方式呼叫 Leaf Server 的各個服務，所以某一個 Client 獲取到的ID序列可能是：1，1001，2001，2，1002，2002。當某個 Leaf Server 號段用完之後，下一次請求就會從 DB 中載入新的號段，這樣保證了每次載入的號段是遞增的。

為了解決在更新DB號段的時出現的耗時和阻塞服務的問題，Leaf 採用了非同步更新的策略，同時透過雙快取的方式，保證無論何時DB出現問題，都能有一個 Buffer 的號段可以正常對外提供服務，只要 DB 在一個 Buffer 的下發的週期內恢復，就不會影響整個 Leaf 的可用性。

除此之外，Leaf 還透過動態調整步長，解決由於步長固定導致的快取中的 ID 被過快消耗問題，以及步長設定過大導致的號段 ID 跨度過大問題，具體公式可去官方文件中瞭解。

對於資料一致性問題，Leaf 目前是透過中介軟體 Zebra 加 MHA 做的主從切換。

1.2. Leaf Snowflake

Leaf-snowflake 方案沿用 Snowflake 方案的 bit 位設計。

對於 workerID 的分配：當服務叢集較小時，透過配置即可；服務叢集較大時，基於 zookeeper 持久順序節點的特性引入 zookeeper 元件配置 workerID。架構如下圖所示：

2. 百度 UidGenerator

開源地址

UidGenerator 方案是基於 Snowflake 演算法的 ID 生成器，其對雪花演算法的 bit 位的分配做了微調。

結構說明（引數可在 Spring Bean 配置中進行配置）：

結構	大小	說明
符號位	1 bit	最高位始終是 0。
增量秒	28 bits	表示自客戶紀元（2016-05-20）以來的增量秒。最大時間為 8.7 年。
工作節點	22 bits	表示工作節點 ID，最大值為 4.2 百萬個。
序列號	13 bits	表示一秒鐘內的序列，預設情況下每秒最多 8192 個。

UidGenerator 方案包含兩種實現方式，DefaultUidGenerator 和 CachedUidGenerator ，效能要求高的情況下推薦 CachedUidGenerator。

3. 滴滴 Tinyid

Tinyid 官方文件

Tinyid 方案是在 Leaf-segment 的演算法基礎上升級而來，不僅支援了資料庫多主節點模式，還提供了 tinyid-client 客戶端的接入方式，使用起來更加方便。

Tinyid 也是採用了非同步加雙快取策略，首先可用號段載入到記憶體中，並在記憶體中生成 ID，可用號段在首次獲取 ID 時載入，號段用到一定程度的時候，就去非同步載入下一個號段，保證記憶體中始終有可用號段，則可避免效能波動。

實現原理如下所示：

五、結語

本文對分散式 ID 以及其場景的生成方案做了介紹，還針對一下大廠的中介軟體進行簡單分析，中介軟體的接入程式碼本文並沒有做詳細介紹，但是官方文件的連結都帖子了每個子標題下，其中都有詳細介紹。

文中還針對每個生成方案的優缺點作出了說明，具體的使用可針對優缺點加上業務需求來進行選型。

---

參考：

[1] 騰訊技術工程. 分散式唯一 ID 生成方案淺談.

[2] 孟斯特. UUID 介紹.

[3] 文丑顏不良啊. 雪花演算法（SnowFlake）.