十種分佈式ID生成方法

什麼是分佈式ID

以MySQL爲例，數據量不大的時候，單庫單表可以支撐現有業務，再大一點主從同步讀寫分離也可以。
但數據是不斷增加的，當主從同步也不行了，就需要分庫分表了。分庫分表需要一個全局唯一ID做標識，這就是分佈式ID。一個能生成分佈式ID的系統是十分有必要的。

分佈式ID特點

全局唯一：基本要求
高性能：高可用低延時，ID生成相應快，否則成爲業務瓶頸；
高可用：不能有單點故障
好接入：在系統設計和實現上儘可能地簡單；
趨勢遞增：在MySQL InnoDB引擎中使用的是聚集索引，由於多數RDBMS使用B-tree的數據結構來存儲索引數據，我們應該儘量使用有序的主鍵保證寫入性能；
單調遞增：保證下一個ID一定大於上一個ID，例如事務版本號、IM增量消息、排序。
信息安全：在一些應用場景下，會需要ID無規則、不規則生成，例如訂單號。
分片支持：可以控制ShardingId。比如某一個用戶的文章要放在同一個分片內，這樣查詢效率高，修改也容易。
長度適中

生成方式

UUID
數據庫自增ID
數據庫多主模式
數據庫號段模式
Redis
雪花算法（SnowFlake）
滴滴出品（TinyID）
百度（Uidgenerator）
美團（Leaf）
zookeeper

1.UUID

UUID uuid=UUID.randomUUID();

UUID的標準形式包含32個16進制數字，以連字號分爲五段，形式爲8-4-4-4-12的36個字符，示例：550e8400-e29b-41d4-a716-446655440000。這種ID每個都是獨一無二的，不用擔心衝突問題。
優點：

生成簡單，本地生成無網絡消耗，有唯一性

缺點：

無序字符串，不具備趨勢遞增的特性；
沒有具體含義；
長度過長對MySQL性能消耗較大；
基於MAC地址生成的UUID可能造成MAC地址泄露

2.數據庫自增ID

基於數據庫的auto_increment自增ID完全可以充當分佈式ID，需要一個單獨的MySQL實例用來生成ID，建表結構如下：

CREATE DATABASE `SEQ_ID`;
CREATE TABLE SEQID.SEQUENCE_ID (
    id bigint(20) unsigned NOT NULL auto_increment, 
    value char(10) NOT NULL default '',
    PRIMARY KEY (id),
) ENGINE=MyISAM;
insert into SEQUENCE_ID(value)  VALUES ('values');

當我們需要一個ID的時候，向表中插入一條記錄返回主鍵ID

優點：

簡單，利用數據庫系統功能實現，成本小，有DBA專業維護
ID號單調遞增

缺點：

太依賴DB，當DB異常時整個系統不可用，屬於致命問題。
配置主從複製可以儘可能的增加可用性，但是數據一致性在特殊情況下難以保證。主從切換時的不一致可能會導致重複發號。
ID發號性能瓶頸限制在單臺MySQL的讀寫性能
訪問量激增時MySQL本身就是系統的瓶頸，用它來實現分佈式服務風險比較大

3.數據庫多主模式

對上邊的方式做一些高可用優化，換成主從模式集羣。再增加多幾個Mysql實例，那就是多主模式集羣了。

設置起始值和自增步長來解決重複ID的問題，例如：
MySQL_1起始值爲1，步長爲2，生成ID：1，3，5…
MySQL_2起始值爲2，步長爲2，生成ID：2，4，6…
當添加多一個MySQL_3時，起始值爲3，步長統一改爲3，那麼就是
1，4，7…
2，5，8…
3，6，9…

優點：解決DB單點問題
缺點：不利於後續擴容，而且實際上單個數據庫自身壓力還是大，依舊無法滿足高併發場景

4.數據庫號段模式

從數據庫批量的獲取自增ID，每次從數據庫取出一個號段範圍，例如 (1,1000] 代表1000個ID，具體的業務服務將本號段，生成1~1000的自增ID並加載到內存。表結構如下：

CREATE TABLE id_generator (
  id int(10) NOT NULL,
  max_id bigint(20) NOT NULL COMMENT '當前最大id',
  step int(20) NOT NULL COMMENT '號段的長度',
  biz_type    int(20) NOT NULL COMMENT '業務類型',
  version int(20) NOT NULL COMMENT '版本號',
  PRIMARY KEY (`id`)
)

不是很依賴於數據庫，不會頻繁的訪問數據庫，對數據庫的壓力小很多。

5.Redis

當使用數據庫來生成ID性能不夠要求的時候，我們可以嘗試使用Redis來生成ID。這主要依賴於Redis是單線程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY來實現。
比較適合使用Redis來生成日切流水號。比如訂單號=日期+當日自增長號。可以每天在Redis中生成一個Key，使用INCR進行累加。

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重啓恢復的數據時間過長。

優點：

不依賴於數據庫，靈活方便，且性能優於數據庫
數字ID天然排序，對分頁或者需要排序的結果很有幫助

缺點：

如果系統中沒有Redis，還需要引入新的組件，增加系統複雜度
需要編碼和配置的工作量比較大
Redis單點故障，影響序列服務的可用性

6.雪花算法（SnowFlake）

是twitter公司內部分佈式項目採用的ID生成算法，開源後廣受國內大廠的好評，在該算法影響下各大公司相繼開發出各具特色的分佈式生成器。

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

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

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

/**
 * 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
    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 
        {
            sequence = 0L;//不同毫秒內，序列號置爲0
        }
        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());
        }
    }
}

7.滴滴出品（TinyID）

先附上項目地址：https://github.com/didi/tinyid

Tinyid是用Java開發的一款分佈式id生成系統，擴展了leaf-segment算法，支持了多db(master)，同時提供了java-client(sdk)使id生成本地化，獲得了更好的性能與可用性。Tinyid在滴滴客服部門使用，均通過tinyid-client方式接入，每天生成億級別的id。
特性：

全局唯一的long型id
趨勢遞增
非連續性
提供http和java client方式接入
支持批量獲取id
支持生成1,3,5,7,9…序列的id
支持多個db的配置，無單點

tinyid的原理：

tinyid是基於數據庫發號算法實現的
可用號段在第一次獲取id時加載，如當前號段使用達到一定量時，會異步加載下一可用號段，保證內存中始終有可用號段。
當使用到一定百分比時，如20%(默認)，即200時，會異步加載下一可用號段到內存。

8.百度（Uidgenerator）

先附上項目地址：https://github.com/baidu/uid-generator

uid-generator是基於Snowflake算法實現的，但uid-generator支持自定義時間戳、工作機器ID和序列號等各部分的位數，而且採用用戶自定義workId的生成策略。
uid-generator需要與數據庫配合使用，需要新增一個WORKER_NODE表。當應用啓動時會向數據庫表中去插入一條數據，插入成功後返回的自增ID就是該機器的workId數據由host，port組成。
ID組成結構：
workId，佔用了22個bit位，時間佔用了28個bit位，序列化佔用了13個bit位，需要注意的是，和snowflake不太一樣，時間的單位是秒，而不是毫秒，workId也不一樣，而且同一應用每次重啓就會消費一個workId。

9.美團（Leaf）

先附上項目地址https://github.com/zhuzhong/idleaf

Leaf同時支持號段模式和snowflake算法模式，可以切換使用。

Leaf的snowflake模式依賴於ZooKeeper，不同於原始snowflake算法也主要是在workId的生成上，Leaf中workId是基於ZooKeeper的順序Id來生成的，每個應用在使用Leaf-snowflake時，啓動時都會都在Zookeeper中生成一個順序Id，相當於一臺機器對應一個順序節點，也就是一個workId。

10.zookeeper

zookeeper主要通過其znode數據版本來生成序列號，可以生成32位和64位的數據版本號，客戶端可以使用這個版本號來作爲唯一的序列號。
很少會使用zookeeper來生成唯一ID。主要是由於需要依賴zookeeper，並且是多步調用API，如果在競爭較大的情況下，需要考慮使用分佈式鎖。因此，性能在高併發的分佈式環境下，也不甚理想。

十種分佈式ID生成方法

什麼是分佈式ID

分佈式ID特點

生成方式

1.UUID

2.數據庫自增ID

3.數據庫多主模式

4.數據庫號段模式

5.Redis

6.雪花算法（SnowFlake）

7.滴滴出品（TinyID）

8.百度（Uidgenerator）

9.美團（Leaf）

10.zookeeper

歡迎關注我的個人公衆號

【面試準備】又一次失敗的面試經歷，題目離譜～資深軟件測試工程師

dotnet 8 版本與銀河麒麟V10和UOS系統的 glibc 兼容性

Java的發展：從Java0到Java14的新特性

Java解析線程池

十種分佈式ID生成方法

MySql引起的CPU消耗你懂嗎

Java文件的運行

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

linux以太網驅動總結

十種分佈式ID生成方法

什麼是分佈式ID

分佈式ID特點

生成方式

1.UUID

2.數據庫自增ID

3.數據庫多主模式

4.數據庫號段模式

5.Redis

6.雪花算法（SnowFlake）

7.滴滴出品（TinyID）

8.百度 （Uidgenerator）

9.美團（Leaf）

10.zookeeper

歡迎關注我的個人公衆號

8.百度（Uidgenerator）