七種分佈式全局 ID 生成策略，你更愛哪種？

@[toc] 上了微服務之後，很多原本很簡單的問題現在都變複雜了，例如全局 ID 這事！

松哥最近工作中剛好用到這塊內容，於是調研了市面上幾種常見的全局 ID 生成策略，稍微做了一下對比，供小夥伴們參考。

當數據庫分庫分表之後，原本的主鍵自增就不方便繼續使用了，需要找到一個新的合適的方案，松哥的需求就是在這樣的情況下提出的。

接下來我們一起來捋一捋。

1. 兩種思路

整體上來說，這個問題有兩種不同的思路：

讓數據庫自己搞定
Java 代碼來處理主鍵，然後直接插入數據庫中即可。

這兩種思路又對應了不同的方案，我們一個一個來看。

2. 數據庫自己搞定

數據庫自己搞定，就是說我在數據插入的時候，依然不考慮主鍵的問題，希望繼續使用數據庫的主鍵自增，但是很明顯，原本默認的主鍵自增現在沒法用了，我們必須有新的方案。

2.1 修改數據庫配置

數據庫分庫分表之後的結構如下圖（假設數據庫中間件用的 MyCat）：

此時如果原本的 db1、db2、db3 繼續各自主鍵自增，那麼對於 MyCat 而言，主鍵就不是自增了，主鍵就會重複，用戶從 MyCat 中查詢到的數據主鍵就有問題。

找到問題的原因，那麼剩下的就好解決了。

我們可以直接修改 MySQL 數據庫主鍵自增的起始值和步長。

首先我們可以通過如下 SQL 查看與此相關的兩個變量的取值：

SHOW VARIABLES LIKE 'auto_increment%'

可以看到，主鍵自增的起始值和步長都是 1。

起始值好改，在定義表的時候就可以設置，步長我們可以通過修改這個配置實現：

set @@auto_increment_increment=9;

修改後，再去查看對應的變量值，發現已經變了：

此時我們再去插入數據，主鍵自增就不是每次自增 1，而是每次自增 9 了。

至於自增起始值其實很好設置，創建表的時候就可以設置了。

create table test01(id integer PRIMARY KEY auto_increment,username varchar(255)) auto_increment=8;

既然 MySQL 可以修改自增的起始值和每次增長的步長，現在假設我有 db1、db2 和 db3，我就可以分別設置這三個庫中表的自增起始值爲 1、2、3，然後自增步長都是 3，這樣就可以實現自增了。

但是很明顯這種方式不夠優雅，而且處理起來很麻煩，將來擴展也不方便，因此不推薦。

2.2 MySQL+MyCat+ZooKeeper

如果大家分庫分表工具恰好使用的是 MyCat，那麼結合 Zookeeper 也能很好的實現主鍵全局自增。

MyCat 作爲一個分佈式數據庫中間，屏蔽了數據庫集羣的操作，讓我們操作數據庫集羣就像操作單機版數據庫一樣，對於主鍵自增，它有自己的方案：

通過本地文件實現
通過數據庫實現
通過本地時間戳實現
通過分佈式 ZK ID 生成器實現
通過 ZK 遞增方式實現

這裏我們主要來看方案 4。

配置步驟如下：

首先修改主鍵自增方式爲 4 ，4 表示使用 zookeeper 實現主鍵自增。

server.xml

配置表自增，並且設置主鍵

schema.xml

設置主鍵自增，並且設置主鍵爲 id 。

配置 zookeeper 的信息

在 myid.properties 中配置 zookeeper 信息：

配置要自增的表

sequence_conf.properties

注意，這裏表名字要大寫。

TABLE.MINID 某線程當前區間內最小值
TABLE.MAXID 某線程當前區間內最大值
TABLE.CURID 某線程當前區間內當前值
文件配置的MAXID以及MINID決定每次取得區間，這個對於每個線程或者進程都有效
文件中的這三個屬性配置只對第一個進程的第一個線程有效，其他線程和進程會動態讀取 ZK

重啓 MyCat 測試

最後重啓 MyCat ，刪掉之前創建的表，然後創建新表進行測試即可。

這種方式就比較省事一些，而且可擴展性也比較強，如果選擇了 MyCat 作爲分庫分表工具，那麼這種不失爲一種最佳方案。

前面介紹這兩種都是在數據庫或者數據庫中間件層面來處理主鍵自增，我們 Java 代碼並不需要額外工作。

接下來我們再來看幾種需要在 Java 代碼中進行處理的方案。

3. Java 代碼處理

3.1 UUID

最容易想到的就是 UUID (Universally Unique Identifier) 了， UUID 的標準型式包含 32 個 16 進制數字，以連字號分爲五段，形式爲 8-4-4-4-12 的 36 個字符，這個是 Java 自帶的，用着也簡單，最大的優勢就是本地生成，沒有網絡消耗，但是但凡在公司做開發的小夥伴都知道這個東西在公司項目中使用並不多。原因如下：

字符串太長，對於 MySQL 而言，不利於索引。
UUID 的隨機性對於 I/O 密集型的應用非常不友好！它會使得聚簇索引的插入變得完全隨機，使得數據沒有任何聚集特性。
信息不安全：基於 MAC 地址生成 UUID 的算法可能會造成 MAC 地址泄露，這個漏洞曾被用於尋找梅麗莎病毒的製作者位置。

因此，UUID 並非最佳方案。

3.2 SNOWFLAKE

雪花算法是由 Twitter 公佈的分佈式主鍵生成算法，它能夠保證不同進程主鍵的不重複性，以及相同進程主鍵的有序性。在同一個進程中，它首先是通過時間位保證不重複，如果時間相同則是通過序列位保證。

同時由於時間位是單調遞增的，且各個服務器如果大體做了時間同步，那麼生成的主鍵在分佈式環境可以認爲是總體有序的，這就保證了對索引字段的插入的高效性。

例如 MySQL 的 Innodb 存儲引擎的主鍵。使用雪花算法生成的主鍵，二進制表示形式包含 4 部分，從高位到低位分表爲：1bit 符號位、41bit 時間戳位、10bit 工作進程位以及 12bit 序列號位。

符號位 (1bit)

預留的符號位，恆爲零。

時間戳位 (41bit)

41 位的時間戳可以容納的毫秒數是 2 的 41 次冪，一年所使用的毫秒數是：365 * 24 * 60 * 60 * 1000。通過計算可知：Math.pow(2, 41) / (365 * 24 * 60 * 60 * 1000L);結果約等於 69.73 年。

ShardingSphere 的雪花算法的時間紀元從 2016 年 11 月 1 日零點開始，可以使用到 2086 年，相信能滿足絕大部分系統的要求。

工作進程位 (10bit)

該標誌在 Java 進程內是唯一的，如果是分佈式應用部署應保證每個工作進程的 id 是不同的。該值默認爲 0，可通過屬性設置。

序列號位 (12bit)

該序列是用來在同一個毫秒內生成不同的 ID。如果在這個毫秒內生成的數量超過 4096 (2 的 12 次冪)，那麼生成器會等待到下個毫秒繼續生成。

> 注意：該算法存在 時鐘回撥 問題，服務器時鐘回撥會導致產生重複序列，因此默認分佈式主鍵生成器提供了一個最大容忍的時鐘回撥毫秒數。如果時鐘回撥的時間超過最大容忍的毫秒數閾值，則程序報錯；如果在可容忍的範圍內，默認分佈式主鍵生成器會等待時鐘同步到最後一次主鍵生成的時間後再繼續工作。最大容忍的時鐘回撥毫秒數的默認值爲 0，可通過屬性設置。

下面松哥給出一個雪花算法的工具類，大家可以參考：

public class IdWorker {
    // 時間起始標記點，作爲基準，一般取系統的最近時間（一旦確定不能變動）
    private final static long twepoch = 1288834974657L;
    // 機器標識位數
    private final static long workerIdBits = 5L;
    // 數據中心標識位數
    private final static long datacenterIdBits = 5L;
    // 機器ID最大值
    private final static long maxWorkerId = -1L ^ (-1L &lt;&lt; workerIdBits);
    // 數據中心ID最大值
    private final static long maxDatacenterId = -1L ^ (-1L &lt;&lt; datacenterIdBits);
    // 毫秒內自增位
    private final static long sequenceBits = 12L;
    // 機器ID偏左移12位
    private final static long workerIdShift = sequenceBits;
    // 數據中心ID左移17位
    private final static long datacenterIdShift = sequenceBits + workerIdBits;
    // 時間毫秒左移22位
    private final static long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;

    private final static long sequenceMask = -1L ^ (-1L &lt;&lt; sequenceBits);
    /* 上次生產id時間戳 */
    private static long lastTimestamp = -1L;
    // 0，併發控制
    private long sequence = 0L;

    private final long workerId;
    // 數據標識id部分
    private final long datacenterId;

    public IdWorker(){
        this.datacenterId = getDatacenterId(maxDatacenterId);
        this.workerId = getMaxWorkerId(datacenterId, maxWorkerId);
    }

    /**
     * @param workerId
     *            工作機器ID
     * @param datacenterId
     *            序列號
     */
    public IdWorker(long workerId, long datacenterId) {
        if (workerId &gt; maxWorkerId || workerId &lt; 0) {
            throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
        }
        if (datacenterId &gt; maxDatacenterId || datacenterId &lt; 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;
    }

    /**
     * 獲取下一個ID
     *
     * @return
     */
    public synchronized long nextId() {
        long timestamp = timeGen();
        if (timestamp &lt; lastTimestamp) {
            throw new RuntimeException(String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
        }

        if (lastTimestamp == timestamp) {
            // 當前毫秒內，則+1
            sequence = (sequence + 1) &amp; sequenceMask;
            if (sequence == 0) {
                // 當前毫秒內計數滿了，則等待下一秒
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0L;
        }
        lastTimestamp = timestamp;
        // ID偏移組合生成最終的ID，並返回ID
        long nextId = ((timestamp - twepoch) &lt;&lt; timestampLeftShift)
                | (datacenterId &lt;&lt; datacenterIdShift)
                | (workerId &lt;&lt; workerIdShift) | sequence;

        return nextId;
    }

    private long tilNextMillis(final long lastTimestamp) {
        long timestamp = this.timeGen();
        while (timestamp &lt;= lastTimestamp) {
            timestamp = this.timeGen();
        }
        return timestamp;
    }

    private long timeGen() {
        return System.currentTimeMillis();
    }

    /**
     * <p>
     * 獲取 maxWorkerId
     * </p>
     */
    protected static long getMaxWorkerId(long datacenterId, long maxWorkerId) {
        StringBuffer mpid = new StringBuffer();
        mpid.append(datacenterId);
        String name = ManagementFactory.getRuntimeMXBean().getName();
        if (!name.isEmpty()) {
            /*
             * GET jvmPid
             */
            mpid.append(name.split("@")[0]);
        }
        /*
         * MAC + PID 的 hashcode 獲取16個低位
         */
        return (mpid.toString().hashCode() &amp; 0xffff) % (maxWorkerId + 1);
    }

    /**
     * <p>
     * 數據標識id部分
     * </p>
     */
    protected static long getDatacenterId(long maxDatacenterId) {
        long id = 0L;
        try {
            InetAddress ip = InetAddress.getLocalHost();
            NetworkInterface network = NetworkInterface.getByInetAddress(ip);
            if (network == null) {
                id = 1L;
            } else {
                byte[] mac = network.getHardwareAddress();
                id = ((0x000000FF &amp; (long) mac[mac.length - 1])
                        | (0x0000FF00 &amp; (((long) mac[mac.length - 2]) &lt;&lt; 8))) &gt;&gt; 6;
                id = id % (maxDatacenterId + 1);
            }
        } catch (Exception e) {
            System.out.println(" getDatacenterId: " + e.getMessage());
        }
        return id;
    }
}

用法如下：

IdWorker idWorker = new IdWorker(0, 0);
for (int i = 0; i &lt; 1000; i++) {
    System.out.println(idWorker.nextId());
}

3.3 LEAF

Leaf 是美團開源的分佈式 ID 生成系統，最早期需求是各個業務線的訂單 ID 生成需求。在美團早期，有的業務直接通過 DB 自增的方式生成 ID，有的業務通過 Redis 緩存來生成 ID，也有的業務直接用 UUID 這種方式來生成 ID。以上的方式各自有各自的問題，因此美團決定實現一套分佈式 ID 生成服務來滿足需求目前 Leaf 覆蓋了美團點評公司內部金融、餐飲、外賣、酒店旅遊、貓眼電影等衆多業務線。在4C8G VM 基礎上，通過公司 RPC 方式調用，QPS 壓測結果近 5w/s，TP999 1ms（TP=Top Percentile，Top 百分數，是一個統計學裏的術語，與平均數、中位數都是一類。TP50、TP90 和 TP99 等指標常用於系統性能監控場景，指高於 50%、90%、99% 等百分線的情況）。

目前 LEAF 的使用有兩種不同的思路，號段模式和 SNOWFLAKE 模式，你可以同時開啓兩種方式，也可以指定開啓某種方式（默認兩種方式爲關閉狀態）。

我們從 GitHub 上 Clone LEAF 之後，它的配置文件在 leaf-server/src/main/resources/leaf.properties 中，各項配置的含義如下：

。

可以看到，如果使用號段模式，需要數據庫支持；如果使用 SNOWFLAKE 模式，需要 Zookeeper 支持。

3.3.1 號段模式

號段模式還是基於數據庫，但是思路有些變化，如下：

利用 proxy server 從數據庫中批量獲取 id，每次獲取一個 segment (step 決定其大小) 號段的值，用完之後再去數據庫獲取新的號段，可以大大的減輕數據庫的壓力。
各個業務不同的發號需求用 biz_tag 字段來區分，每個 biz-tag 的 ID 獲取相互隔離，互不影響。
如果有新的業務需要擴區 ID，只需要增加表記錄即可。

如果使用號段模式，我們首先需要創建一張數據表，腳本如下：

CREATE DATABASE leaf
CREATE TABLE `leaf_alloc` (
  `biz_tag` varchar(128)  NOT NULL DEFAULT '',
  `max_id` bigint(20) NOT NULL DEFAULT '1',
  `step` int(11) NOT NULL,
  `description` varchar(256)  DEFAULT NULL,
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;

insert into leaf_alloc(biz_tag, max_id, step, description) values('leaf-segment-test', 1, 2000, 'Test leaf Segment Mode Get Id')

這張表中各項字段的含義如下：

biz_tag：業務標記（不同業務可以有不同的號段序列）
max_id：當前號段下的最大 id
step：每次取號段的步長
description：描述信息
update_time：更新時間

配置完成後，啓動項目，訪問 http://localhost:8080/api/segment/get/leaf-segment-test 路徑（路徑最後面的 leaf-segment-test 是業務標記），即可拿到 ID。

可以通過如下地址訪問到號段模式的監控頁面 http://localhost:8080/cache。

號段模式優缺點：

優點

Leaf 服務可以很方便的線性擴展，性能完全能夠支撐大多數業務場景。
ID 號碼是趨勢遞增的 8byte 的 64 位數字，滿足上述數據庫存儲的主鍵要求。
容災性高：Leaf 服務內部有號段緩存，即使 DB 宕機，短時間內 Leaf 仍能正常對外提供服務。
可以自定義 max_id 的大小，非常方便業務從原有的 ID 方式上遷移過來。

缺點

ID 號碼不夠隨機，能夠泄露發號數量的信息，不太安全。
DB 宕機會造成整個系統不可用。

3.3.2 SNOWFLAKE 模式

SNOWFLAKE 模式需要配合 Zookeeper 一起，不過 SNOWFLAKE 對 Zookeeper 的依賴是弱依賴，把 Zookeeper 啓動之後，我們可以在 SNOWFLAKE 中配置 Zookeeper 信息，如下：

leaf.snowflake.enable=true
leaf.snowflake.zk.address=192.168.91.130
leaf.snowflake.port=2183

然後重新啓動項目，啓動成功後，通過如下地址可以訪問到 ID：

http://localhost:8080/api/snowflake/get/test

3.4 Redis 生成

這個主要是利用 Redis 的 incrby 來實現，這個我覺得沒啥好說的。

3.5 Zookeeper 處理

zookeeper 也能做，但是比較麻煩，不推薦。

4. 小結

綜上，如果項目中恰好使用了 MyCat，那麼可以使用 MyCat+Zookeeper，否則建議使用 LEAF，兩種模式皆可。

七種分佈式全局 ID 生成策略，你更愛哪種？

1. 兩種思路

2. 數據庫自己搞定

2.1 修改數據庫配置

2.2 MySQL+MyCat+ZooKeeper

3. Java 代碼處理

3.1 UUID

3.2 SNOWFLAKE

3.3 LEAF

3.3.1 號段模式

3.3.2 SNOWFLAKE 模式

3.4 Redis 生成

3.5 Zookeeper 處理

4. 小結

哈哈哈哈或

【自用】關於微信小程序的合法域名列表，

使用 @NoRepositoryBean 簡化數據庫訪問

MySQL查出時間比實際晚8小時的解決方案

什麼是IPD項目管理模式？聊聊IPD下的產品研發流程

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結