分散式ID策略為什麼要用分散式ID？在我們業務數據量不大的時候，單庫單表完全可以支撐現有業務，數據再大一點搞個 MySQL 主從同步讀寫分離也能對付。但隨著數據日漸增長，主從同步也扛不住了，就需要對資料庫進行分庫分表，但分庫分表後需要有一個唯一ID來標識一條數據，資料庫的自增ID顯然不能滿足需 ...

分散式ID策略

為什麼要用分散式ID？

在我們業務數據量不大的時候，單庫單表完全可以支撐現有業務，數據再大一點搞個 MySQL 主從同步讀寫分離也能對付。

但隨著數據日漸增長，主從同步也扛不住了，就需要對資料庫進行分庫分表，但分庫分表後需要有一個唯一ID來標識一條數據，資料庫的自增ID顯然不能滿足需求；特別一點的如訂單、優惠券也都需要有唯一ID做標識。此時一個能夠生成全局唯一ID的系統是非常必要的。那麼這個全局唯一ID就叫分散式ID。

分散式ID要滿足什麼特性？

唯一性：必須保證ID是全局性唯一的，這是基本要求；

高性能：高可用低延時，ID生成響應要塊，否則反倒會成為業務瓶頸；

高可用：需要保證高併發下的可用性。除了對 ID 號碼自身的要求，業務還對 ID 生成系統的可用性要求極高；

遞增性：生成的 ID 需要按照某種規則有序，便於資料庫的寫入和排序操作；

安全性：

id的規律性太明顯，用戶就會知曉該店鋪每天的訂單量，暴露隱私；
受單表數據量的限制，訂單的數據量較大，訂單量隨著時間會不斷增大，如果訂單量已經達到了上億，那單張表保存不了這麼龐大的數據。如果分為多張表來保存訂單數據，多張表訂單ID都是從1開始增長，那ID一定會出現重覆。

分散式ID生成方式有哪些？

1、UUID

UUID，它有著全球唯一的特性。UUID可以做分散式ID，但並不推薦使用。

UUID 的標準形式為 32 個十六進位數組成的字元串，且分割為五個部分

String uuid = UUID.randomUUID().toString().replaceAll("-","");;

UUID的生成簡單到只有一行代碼，輸出結果 2fedcf5e38ac4bf78f6ab6035005eea2，但UUID卻並不適用於實際的業務需求。像用作訂單號UUID這樣的字元串沒有絲毫的意義，看不出和訂單相關的有用信息；而對於資料庫來說，用作業務主鍵ID，它不僅太長而且還是字元串，存儲性能差，查詢也很耗時，所以不推薦用作分散式ID。

優點：

生成足夠簡單，本地生成無網路消耗，具有唯一性；

缺點：

無序的字元串；
沒有具體的業務含義；
長度過長，16 位元組128位，36位長度的字元串（加上四個“-”），存儲以及查詢對MySQL的性能消耗較大。(MySQL官方明確建議主鍵儘量越短越好，作為資料庫主鍵 UUID 的無序性會導致數據位置頻繁變動，嚴重影響性能)；

2、資料庫自增ID

基於資料庫的auto_increment自增ID完全可以充當分散式ID，在資料庫內可以保證唯一。

優點：

實現簡單，ID單調自增，數值類型查詢速度快；

缺點：

DB單點存在宕機風險，無法扛住高併發場景，因為資料庫要承載每秒幾萬併發，肯定是不現實的。

3、資料庫集群自增ID

上面的單點資料庫方式不可取，那對上邊的方式做一些高可用優化，換成主從模式集群。害怕一個主節點掛掉沒法用，那就做雙主模式集群，也就是兩個 Mysql 實例都能單獨的生產自增ID。

那這樣還會有個問題，兩個MySQL實例的自增ID都從1開始，會生成重覆的ID怎麼辦？

解決方案：設置不同的起始值和相同的自增步長

舉個例子：

# MySQL_1 配置
set @@auto_increment_offset = 1;     -- 起始值
set @@auto_increment_increment = 3;  -- 步長

# MySQL_2 配置
set @@auto_increment_offset = 2;     -- 起始值
set @@auto_increment_increment = 3;  -- 步長

# MySQL_3 配置
set @@auto_increment_offset = 3;     -- 起始值
set @@auto_increment_increment = 3;  -- 步長

這樣兩個MySQL實例的自增ID分別就是：

1、4、7、10...
2、5、8、11...
3、6、9、12...

但是存在一個問題，如果後續需要擴展集群，增加一臺MySQL機器，就需要修改前3台MySQL實例的起始值和步長。

優點：

解決DB單點問題；

缺點：

不利於後續擴容，而且實際上單個資料庫自身壓力還是大，依舊無法滿足高併發場景。

4、Redis自增ID

string有自增特性，能夠確保唯一性，利用redis的 incr命令實現ID的原子性自增。

127.0.0.1:6379> set seq_id 1     // 初始化自增ID為1
OK
127.0.0.1:6379> incr seq_id      // 增加1，並返回遞增後的數值
(integer) 2

用redis實現需要註意一點，要考慮到redis持久化的問題。redis有兩種持久化方式RDB和AOF：

RDB會定時打一個快照進行持久化，假如連續自增但redis沒及時持久化，而這會Redis掛掉了，重啟Redis後會出現ID重覆的情況；
AOF會對每條寫命令進行持久化，即使Redis掛掉了也不會出現ID重覆的情況，但由於incr命令的特殊性，會導致Redis重啟恢復的數據時間過長。

5、雪花演算法

雪花演算法（Snowflake）是twitter公司內部分散式項目採用的ID生成演算法。

相比 UUID 無序生成的id而言，雪花演算法是有序的，而且都是由數字組成。雪花id最大為64位，符合java中long的長度64位，拋去一位符號位，那麼最大為2⁶³。

Snowflake生成的是Long類型的ID，一個Long類型占8個位元組，每個位元組占8比特，也就是說一個Long類型占64個比特。

Snowflake ID組成結構：正數位（占1比特）+ 時間戳（占41比特）+ 數據中心（機房）（占5比特）+ 機器ID（占5比特）+ 自增值（占12比特），總共64比特組成的一個Long類型。

第一個bit位（1bit）：Java中long的最高位是符號位代表正負，正數是0，負數是1，一般生成ID都為正數，所以預設為0；
時間戳部分（41bit）：毫秒級的時間，不建議存當前時間戳，而是用（當前時間戳 - 固定開始時間戳）的差值，可以使產生的ID從更小的值開始；41位的時間戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
工作機器id（10bit）：也被叫做workId，這個可以靈活配置，機房或者機器號組合都可以；
序列號部分（12bit），自增值支持同一毫秒內同一個節點可以生成2^12 = 4096個ID；

根據這個演算法的邏輯，只需要將這個演算法用Java語言實現出來，封裝為一個工具方法，那麼各個業務應用可以直接使用該工具方法來獲取分散式ID，只需保證每個業務應用有自己的工作機器id即可，而不需要單獨去搭建一個獲取分散式ID的應用。

改進：

在生成唯一id的時候，一般都需要指定一個表名，比如說訂單表的唯一id。所以上面那64個bit中，代表機房的那5個bit，可以使用業務表名稱來替代，比如用00001代表的是訂單表。因為其實很多時候，機房並沒有那麼多（大廠除外），所以前5個bit用做機房id可能意義不是太大。

這樣就可以做到，snowflake演算法系統的每一臺機器，對一個業務表，在某一毫秒內，可以生成一個唯一的id，一毫秒內生成很多id，用最後12個bit來區分序號對待。

Java版本的雪花演算法實現：

/**
 * Twitter的SnowFlake演算法,使用SnowFlake演算法生成一個整數，然後轉化為62進位變成一個短地址URL
 *
 * https://github.com/beyondfengyu/SnowFlake
 */
public class SnowFlakeShortUrl {

    /**
     * 起始的時間戳
     */
    private final static long START_TIMESTAMP = 1480166465631L;

    /**
     * 每一部分占用的位數
     */
    private final static long SEQUENCE_BIT = 12;   //序列號占用的位數
    private final static long MACHINE_BIT = 5;     //機器標識占用的位數
    private final static long DATA_CENTER_BIT = 5; //數據中心占用的位數

    /**
     * 每一部分的最大值
     */
    private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);
    private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
    private final static long MAX_DATA_CENTER_NUM = -1L ^ (-1L << DATA_CENTER_BIT);

    /**
     * 每一部分向左的位移
     */
    private final static long MACHINE_LEFT = SEQUENCE_BIT;
    private final static long DATA_CENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
    private final static long TIMESTAMP_LEFT = DATA_CENTER_LEFT + DATA_CENTER_BIT;

    private long dataCenterId;  //數據中心
    private long machineId;     //機器標識
    private long sequence = 0L; //序列號
    private long lastTimeStamp = -1L;  //上一次時間戳

    private long getNextMill() {
        long mill = getNewTimeStamp();
        while (mill <= lastTimeStamp) {
            mill = getNewTimeStamp();
        }
        return mill;
    }

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

    /**
     * 根據指定的數據中心ID和機器標誌ID生成指定的序列號
     *
     * @param dataCenterId 數據中心ID
     * @param machineId    機器標誌ID
     */
    public SnowFlakeShortUrl(long dataCenterId, long machineId) {
        if (dataCenterId > MAX_DATA_CENTER_NUM || dataCenterId < 0) {
            throw new IllegalArgumentException("DtaCenterId can't be greater than MAX_DATA_CENTER_NUM or less than 0！");
        }
        if (machineId > MAX_MACHINE_NUM || machineId < 0) {
            throw new IllegalArgumentException("MachineId can't be greater than MAX_MACHINE_NUM or less than 0！");
        }
        this.dataCenterId = dataCenterId;
        this.machineId = machineId;
    }

    /**
     * 產生下一個ID
     *
     * @return
     */
    public synchronized long nextId() {
        long currTimeStamp = getNewTimeStamp();
        if (currTimeStamp < lastTimeStamp) {
            throw new RuntimeException("Clock moved backwards.  Refusing to generate id");
        }

        if (currTimeStamp == lastTimeStamp) {
            //相同毫秒內，序列號自增
            sequence = (sequence + 1) & MAX_SEQUENCE;
            //同一毫秒的序列數已經達到最大
            if (sequence == 0L) {
                currTimeStamp = getNextMill();
            }
        } else {
            //不同毫秒內，序列號置為0
            sequence = 0L;
        }

        lastTimeStamp = currTimeStamp;

        return (currTimeStamp - START_TIMESTAMP) << TIMESTAMP_LEFT //時間戳部分
                | dataCenterId << DATA_CENTER_LEFT       //數據中心部分
                | machineId << MACHINE_LEFT             //機器標識部分
                | sequence;                             //序列號部分
    }

    public static void main(String[] args) {
        SnowFlakeShortUrl snowFlake = new SnowFlakeShortUrl(2, 3);

        for (int i = 0; i < (1 << 4); i++) {
            //10進位
            System.out.println(snowFlake.nextId());
        }
    }
}

參考

https://mp.weixin.qq.com/s/c1DsYzBrZ6nfJi4z8xEIvg

分散式ID生成方案