一口氣說出 9種分佈式ID生成方式，面試官有點懵了

時間 2020-02-18

原文原文鏈接

整理了一些Java方面的架構、面試資料（微服務、集羣、分佈式、中間件等），有須要的小夥伴能夠關注公衆號【程序員內點事】，無套路自行領取javascript

本文做者：程序員內點事原文連接：mp.weixin.qq.com/s?__biz=MzA…java

更多精選mysql

寫在前邊

前兩天公衆號有個粉絲給我留言吐槽最近面試：「四哥，年前我在公司受點委屈一衝動就裸辭了，而後如今疫情嚴重兩個多月還沒找到工做，接了幾個視頻面試也都沒下文。好多面試官問完一個問題，緊接着說還會其餘解決方法嗎？能幹活解決bug不就好了嗎？那還得會多少種方法？」git

面試官應該是對應聘者的回答不太滿意，他想聽到一個他認爲最優的解決方案，其實這無可厚非。一樣一個bug，能用一行代碼解決問題的人和用十行代碼解決問題的人，你會選哪一個入職？顯而易見的事情！因此看待問題仍是要從多個角度出發，每種方法都有各自的利弊。程序員

1、爲何要用分佈式ID？

在說分佈式ID的具體實現以前，咱們來簡單分析一下爲何用分佈式ID？分佈式ID應該知足哪些特徵？github

一、什麼是分佈式ID？

拿MySQL數據庫舉個栗子：面試

在咱們業務數據量不大的時候，單庫單表徹底能夠支撐現有業務，數據再大一點搞個MySQL主從同步讀寫分離也能對付。redis

但隨着數據日漸增加，主從同步也扛不住了，就須要對數據庫進行分庫分表，但分庫分表後須要有一個惟一ID來標識一條數據，數據庫的自增ID顯然不能知足需求；特別一點的如訂單、優惠券也都須要有惟一ID作標識。此時一個可以生成全局惟一ID的系統是很是必要的。那麼這個全局惟一ID就叫分佈式ID。算法

二、那麼分佈式ID須要知足那些條件？

全局惟一：必須保證ID是全局性惟一的，基本要求
高性能：高可用低延時，ID生成響應要塊，不然反倒會成爲業務瓶頸
高可用：100%的可用性是騙人的，可是也要無限接近於100%的可用性
好接入：要秉着拿來即用的設計原則，在系統設計和實現上要儘量的簡單
趨勢遞增：最好趨勢遞增，這個要求就得看具體業務場景了，通常不嚴格要求

2、分佈式ID都有哪些生成方式？

今天主要分析一下如下9種，分佈式ID生成器方式以及優缺點：sql

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

那麼它們都是如何實現？以及各自有什麼優缺點？咱們往下看

以上圖片源自網絡，若有侵權聯繫刪除

一、基於UUID

在Java的世界裏，想要獲得一個具備惟一性的ID，首先被想到可能就是UUID，畢竟它有着全球惟一的特性。那麼UUID能夠作分佈式ID嗎？答案是能夠的，可是並不推薦！

public static void main(String[] args) { 
       String uuid = UUID.randomUUID().toString().replaceAll("-","");
       System.out.println(uuid);
 }
複製代碼

UUID的生成簡單到只有一行代碼，輸出結果 c2b8c2b9e46c47e3b30dca3b0d447718，但UUID卻並不適用於實際的業務需求。像用做訂單號UUID這樣的字符串沒有絲毫的意義，看不出和訂單相關的有用信息；而對於數據庫來講用做業務主鍵ID，它不只是太長仍是字符串，存儲性能差查詢也很耗時，因此不推薦用做分佈式ID。

優勢：

生成足夠簡單，本地生成無網絡消耗，具備惟一性

缺點：

無序的字符串，不具有趨勢自增特性
沒有具體的業務含義
長度過長16 字節128位，36位長度的字符串，存儲以及查詢對MySQL的性能消耗較大，MySQL官方明確建議主鍵要儘可能越短越好，做爲數據庫主鍵 UUID 的無序性會致使數據位置頻繁變更，嚴重影響性能。

二、基於數據庫自增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，但這種方式有一個比較致命的缺點，訪問量激增時MySQL自己就是系統的瓶頸，用它來實現分佈式服務風險比較大，不推薦！

優勢：

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

缺點：

DB單點存在宕機風險，沒法扛住高併發場景

三、基於數據庫集羣模式

前邊說了單點數據庫方式不可取，那對上邊的方式作一些高可用優化，換成主從模式集羣。懼怕一個主節點掛掉無法用，那就作雙主模式集羣，也就是兩個Mysql實例都能單獨的生產自增ID。

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

解決方案：設置起始值和自增步長

MySQL_1 配置：

set @@auto_increment_offset = 1;     -- 起始值
set @@auto_increment_increment = 2;  -- 步長
複製代碼

MySQL_2 配置：

set @@auto_increment_offset = 2;     -- 起始值
set @@auto_increment_increment = 2;  -- 步長
複製代碼

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

一、三、五、七、9 二、四、六、八、10

那若是集羣后的性能仍是扛不住高併發咋辦？就要進行MySQL擴容增長節點，這是一個比較麻煩的事。

從上圖能夠看出，水平擴展的數據庫集羣，有利於解決數據庫單點壓力的問題，同時爲了ID生成特性，將自增步長按照機器數量來設置。

增長第三臺MySQL實例須要人工修改1、二兩臺MySQL實例的起始值和步長，把第三臺機器的ID起始生成位置設定在比現有最大自增ID的位置遠一些，但必須在1、二兩臺MySQL實例ID尚未增加到第三臺MySQL實例的起始ID值的時候，不然自增ID就要出現重複了，必要時可能還須要停機修改。

優勢：

解決DB單點問題

缺點：

不利於後續擴容，並且實際上單個數據庫自身壓力仍是大，依舊沒法知足高併發場景。

四、基於數據庫的號段模式

號段模式是當下分佈式ID生成器的主流實現方式之一，號段模式能夠理解爲從數據庫批量的獲取自增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`)
) 
複製代碼

biz_type ：表明不一樣業務類型

max_id ：當前最大的可用id

step ：表明號段的長度

version ：是一個樂觀鎖，每次都更新version，保證併發時數據的正確性

id	biz_type	max_id	step	version
1	101	1000	2000	0

等這批號段ID用完，再次向數據庫申請新號段，對max_id字段作一次update操做，update max_id= max_id + step，update成功則說明新號段獲取成功，新的號段範圍是(max_id ,max_id +step]。

update id_generator set max_id = #{max_id+step}, version = version + 1 where version = # {version} and biz_type = XXX
複製代碼

因爲多業務端可能同時操做，因此採用版本號version樂觀鎖方式更新，這種分佈式ID生成方式不強依賴於數據庫，不會頻繁的訪問數據庫，對數據庫的壓力小不少。

五、基於Redis模式

Redis也一樣能夠實現，原理就是利用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重啓恢復的數據時間過長。

六、基於雪花算法（Snowflake）模式

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

以上圖片源自網絡，若有侵權聯繫刪除

Snowflake生成的是Long類型的ID，一個Long類型佔8個字節，每一個字節佔8比特，也就是說一個Long類型佔64個比特。

Snowflake ID組成結構：正數位（佔1比特）+ 時間戳（佔41比特）+ 機器ID（佔5比特）+ 數據中心（佔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），自增值支持同一毫秒內同一個節點能夠生成4096個ID

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

Java版本的Snowflake算法實現：

/** * 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());
        }
    }
}
複製代碼

七、百度（uid-generator）

uid-generator是由百度技術部開發，項目GitHub地址 github.com/baidu/uid-g…

uid-generator是基於Snowflake算法實現的，與原始的snowflake算法不一樣在於，uid-generator支持自定義時間戳、工做機器ID和 序列號 等各部分的位數，並且uid-generator中採用用戶自定義workId的生成策略。

uid-generator須要與數據庫配合使用，須要新增一個WORKER_NODE表。當應用啓動時會向數據庫表中去插入一條數據，插入成功後返回的自增ID就是該機器的workId數據由host，port組成。

對於uid-generator ID組成結構：

workId，佔用了22個bit位，時間佔用了28個bit位，序列化佔用了13個bit位，須要注意的是，和原始的snowflake不太同樣，時間的單位是秒，而不是毫秒，workId也不同，並且同一應用每次重啓就會消費一個workId。

參考文獻 github.com/baidu/uid-g…

八、美團（Leaf）

Leaf由美團開發，github地址：github.com/Meituan-Dia…

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

號段模式

先導入源碼 github.com/Meituan-Dia… ，在建一張表leaf_alloc

DROP TABLE IF EXISTS `leaf_alloc`;

CREATE TABLE `leaf_alloc` (
  `biz_tag` varchar(128)  NOT NULL DEFAULT '' COMMENT '業務key',
  `max_id` bigint(20) NOT NULL DEFAULT '1' COMMENT '當前已經分配了的最大id',
  `step` int(11) NOT NULL COMMENT '初始步長，也是動態調整的最小步長',
  `description` varchar(256)  DEFAULT NULL COMMENT '業務key的描述',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '數據庫維護的更新時間',
  PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;

複製代碼

而後在項目中開啓號段模式，配置對應的數據庫信息，並關閉snowflake模式

leaf.name=com.sankuai.leaf.opensource.test
leaf.segment.enable=true
leaf.jdbc.url=jdbc:mysql://localhost:3306/leaf_test?useUnicode=true&characterEncoding=utf8&characterSetResults=utf8
leaf.jdbc.username=root
leaf.jdbc.password=root

leaf.snowflake.enable=false
#leaf.snowflake.zk.address=
#leaf.snowflake.port=

複製代碼

啓動leaf-server 模塊的 LeafServerApplication項目就跑起來了

號段模式獲取分佈式自增ID的測試url ：http：//localhost：8080/api/segment/get/leaf-segment-test

監控號段模式：http://localhost:8080/cache

snowflake模式

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

leaf.snowflake.enable=true
leaf.snowflake.zk.address=127.0.0.1
leaf.snowflake.port=2181
複製代碼

snowflake模式獲取分佈式自增ID的測試url：http://localhost:8080/api/snowflake/get/test

九、滴滴（Tinyid）

Tinyid由滴滴開發，Github地址：github.com/didi/tinyid…

Tinyid是基於號段模式原理實現的與Leaf一模一樣，每一個服務獲取一個號段（1000,2000]、（2000,3000]、（3000,4000]

Tinyid提供 http和 tinyid-client兩種方式接入

Http方式接入

（1）導入Tinyid源碼：

git clone github.com/didi/tinyid…

（2）建立數據表：

CREATE TABLE `tiny_id_info` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  `biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '業務類型，惟一',
  `begin_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '開始id，僅記錄初始值，無其餘含義。初始化時begin_id和max_id應相同',
  `max_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '當前最大id',
  `step` int(11) DEFAULT '0' COMMENT '步長',
  `delta` int(11) NOT NULL DEFAULT '1' COMMENT '每次id增量',
  `remainder` int(11) NOT NULL DEFAULT '0' COMMENT '餘數',
  `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '建立時間',
  `update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新時間',
  `version` bigint(20) NOT NULL DEFAULT '0' COMMENT '版本號',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_biz_type` (`biz_type`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'id信息表';

CREATE TABLE `tiny_id_token` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',
  `token` varchar(255) NOT NULL DEFAULT '' COMMENT 'token',
  `biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '此token可訪問的業務類型標識',
  `remark` varchar(255) NOT NULL DEFAULT '' COMMENT '備註',
  `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '建立時間',
  `update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新時間',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'token信息表';

INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)
VALUES
	(1, 'test', 1, 1, 100000, 1, 0, '2018-07-21 23:52:58', '2018-07-22 23:19:27', 1);

INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)
VALUES
	(2, 'test_odd', 1, 1, 100000, 2, 1, '2018-07-21 23:52:58', '2018-07-23 00:39:24', 3);


INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`)
VALUES
	(1, '0f673adf80504e2eaa552f5d791b644c', 'test', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');

INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`)
VALUES
	(2, '0f673adf80504e2eaa552f5d791b644c', 'test_odd', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');
複製代碼

（3）配置數據庫：

datasource.tinyid.names=primary
datasource.tinyid.primary.driver-class-name=com.mysql.jdbc.Driver
datasource.tinyid.primary.url=jdbc:mysql://ip:port/databaseName?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8
datasource.tinyid.primary.username=root
datasource.tinyid.primary.password=123456
複製代碼

（4）啓動tinyid-server後測試

獲取分佈式自增ID: http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c'
返回結果: 3

批量獲取分佈式自增ID:
http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c&batchSize=10'
返回結果:  4,5,6,7,8,9,10,11,12,13
複製代碼

Java客戶端方式接入

重複Http方式的（2）（3）操做

引入依賴

<dependency>
            <groupId>com.xiaoju.uemc.tinyid</groupId>
            <artifactId>tinyid-client</artifactId>
            <version>${tinyid.version}</version>
        </dependency>
複製代碼

配置文件

tinyid.server =localhost:9999
tinyid.token =0f673adf80504e2eaa552f5d791b644c
複製代碼

test 、tinyid.token是在數據庫表中預先插入的數據，test 是具體業務類型，tinyid.token表示可訪問的業務類型

// 獲取單個分佈式自增ID
Long id =  TinyId . nextId( " test " );

// 按需批量分佈式自增ID
List< Long > ids =  TinyId . nextId( " test " , 10 );
複製代碼

總結

本文只是簡單介紹一下每種分佈式ID生成器，旨在給你們一個詳細學習的方向，每種生成方式都有它本身的優缺點，具體如何使用還要看具體的業務需求。

今天就說這麼多，若是本文對您有一點幫助，但願能獲得您一個點贊👍哦

您的承認纔是我寫做的動力！

整理了一些Java方面的架構、面試資料（微服務、集羣、分佈式、中間件等），有須要的小夥伴能夠關注公衆號【程序員內點事】，無套路自行領取

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。

一口氣說出 9種 分佈式ID生成方式，面試官有點懵了

寫在前邊

1、爲何要用分佈式ID？

一、什麼是分佈式ID？

二、那麼分佈式ID須要知足那些條件？

2、 分佈式ID都有哪些生成方式？

一、基於UUID

二、基於數據庫自增ID

三、基於數據庫集羣模式

四、基於數據庫的號段模式

五、基於Redis模式

六、基於雪花算法（Snowflake）模式

七、百度（uid-generator）

八、美團（Leaf）

號段模式

snowflake模式

九、滴滴（Tinyid）

Http方式接入

Java客戶端方式接入

總結

一口氣說出 9種分佈式ID生成方式，面試官有點懵了

2、分佈式ID都有哪些生成方式？