一、為什麼要用分散式ID？

在說分散式ID的具體實現之前，我們來簡單分析一下為什麼用分散式ID？分散式ID應該滿足哪些特徵？

1、什麼是分散式ID？

拿MySQL資料庫舉個栗子：在我們業務資料量不大的時候，單庫單表完全可以支撐現有業務，資料再大一點搞個MySQL主從同步讀寫分離也能對付。但隨著資料日漸增長，主從同步也扛不住了，就需要對資料庫進行分庫分表，但分庫分表後需要有一個唯一ID來標識一條資料，資料庫的自增ID顯然不能滿足需求；特別一點的如訂單、優惠券也都需要有唯一ID做標識。此時一個能夠生成全域性唯一ID的系統是非常必要的。那麼這個全域性唯一ID就叫分散式ID。

2、那麼分散式ID需要滿足那些條件？

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

二、 分散式ID都有哪些生成方式？

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

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

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

以上圖片源自網路，如有侵權聯絡刪除

1、基於UUID

在Java的世界裡，想要得到一個具有唯一性的ID，首先被想到可能就是UUID，畢竟它有著全球唯一的特性。那麼UUID可以做分散式ID嗎？答案是可以的，但是並不推薦！

publicstaticvoidmain(String[]args){
Stringuuid=UUID.randomUUID().toString().replaceAll("-","");
System.out.println(uuid);
}

UUID的生成簡單到只有一行程式碼，輸出結果c2b8c2b9e46c47e3b30dca3b0d447718，但UUID卻並不適用於實際的業務需求。像用作訂單號UUID

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

缺點：

• 無序的字串，不具備趨勢自增特性
• 沒有具體的業務含義
• 長度過長16 位元組128位，36位長度的字串，儲存以及查詢對MySQL的效能消耗較大，MySQL官方明確建議主鍵要儘量越短越好，作為資料庫主鍵UUID的無序性會導致資料位置頻繁變動，嚴重影響效能。

2、基於資料庫自增ID

基於資料庫的auto_increment自增ID完全可以充當分散式ID，具體實現：需要一個單獨的MySQL例項用來生成ID，建表結構如下：

CREATEDATABASE`SEQ_ID`;
CREATETABLESEQID.SEQUENCE_ID(
idbigint(20)unsignedNOTNULLauto_increment,
valuechar(10)NOTNULLdefault'',
PRIMARYKEY(id),
)ENGINE=MyISAM;

insertintoSEQUENCE_ID(value)VALUES('values');

當我們需要一個ID的時候，向表中插入一條記錄返回主鍵ID，但這種方式有一個比較致命的缺點，訪問量激增時MySQL本身就是系統的瓶頸，用它來實現分散式服務風險比較大，不推薦！優點：

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

缺點：

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

3、基於資料庫叢集模式

前邊說了單點資料庫方式不可取，那對上邊的方式做一些高可用優化，換成主從模式叢集。害怕一個主節點掛掉沒法用，那就做雙主模式叢集，也就是兩個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分別就是：

1、3、5、7、9
2、4、6、8、10

那如果集群后的效能還是扛不住高併發咋辦？就要進行MySQL擴容增加節點，這是一個比較麻煩的事。在這裡插入圖片描述
從上圖可以看出，水平擴充套件的資料庫叢集，有利於解決資料庫單點壓力的問題，同時為了ID生成特性，將自增步長按照機器數量來設定。增加第三臺MySQL例項需要人工修改一、二兩臺MySQL例項的起始值和步長，把第三臺機器的ID起始生成位置設定在比現有最大自增ID的位置遠一些，但必須在一、二兩臺MySQL例項ID還沒有增長到第三臺MySQL例項的起始ID值的時候，否則自增ID就要出現重複了，必要時可能還需要停機修改。優點：

• 解決DB單點問題

缺點：

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

4、基於資料庫的號段模式

號段模式是當下分散式ID生成器的主流實現方式之一，號段模式可以理解為從資料庫批量的獲取自增ID，每次從資料庫取出一個號段範圍，例如 (1,1000] 代表1000個ID，具體的業務服務將本號段，生成1~1000的自增ID並載入到記憶體。表結構如下：

CREATETABLEid_generator(
idint(10)NOTNULL,
max_idbigint(20)NOTNULLCOMMENT'當前最大id',
stepint(20)NOTNULLCOMMENT'號段的布長',
biz_typeint(20)NOTNULLCOMMENT'業務型別',
versionint(20)NOTNULLCOMMENT'版本號',
PRIMARYKEY(`id`)
)

biz_type ：代表不同業務型別max_id ：當前最大的可用idstep ：代表號段的長度version ：是一個樂觀鎖，每次都更新version，保證併發時資料的正確性idbiz_typemax_idstepversion

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

updateid_generatorsetmax_id=#{max_id+step},version=version+1whereversion=#{version}andbiz_type=XXX

由於多業務端可能同時操作，所以採用版本號version樂觀鎖方式更新，這種分散式ID生成方式不強依賴於資料庫，不會頻繁的訪問資料庫，對資料庫的壓力小很多。

5、基於Redis模式

Redis也同樣可以實現，原理就是利用redis的incr命令實現ID的原子性自增。

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

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

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

6、基於雪花演算法（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
*/
publicclassSnowFlakeShortUrl{

/**
*起始的時間戳
*/
privatefinalstaticlongSTART_TIMESTAMP=1480166465631L;

/**
*每一部分佔用的位數
*/
privatefinalstaticlongSEQUENCE_BIT=12;//序列號佔用的位數
privatefinalstaticlongMACHINE_BIT=5;//機器標識佔用的位數
privatefinalstaticlongDATA_CENTER_BIT=5;//資料中心佔用的位數

/**
*每一部分的最大值
*/
privatefinalstaticlongMAX_SEQUENCE=-1L^(-1L<<SEQUENCE_BIT);
privatefinalstaticlongMAX_MACHINE_NUM=-1L^(-1L<<MACHINE_BIT);
privatefinalstaticlongMAX_DATA_CENTER_NUM=-1L^(-1L<<DATA_CENTER_BIT);

/**
*每一部分向左的位移
*/
privatefinalstaticlongMACHINE_LEFT=SEQUENCE_BIT;
privatefinalstaticlongDATA_CENTER_LEFT=SEQUENCE_BIT+MACHINE_BIT;
privatefinalstaticlongTIMESTAMP_LEFT=DATA_CENTER_LEFT+DATA_CENTER_BIT;

privatelongdataCenterId;//資料中心
privatelongmachineId;//機器標識
privatelongsequence=0L;//序列號
privatelonglastTimeStamp=-1L;//上一次時間戳

privatelonggetNextMill(){
longmill=getNewTimeStamp();
while(mill<=lastTimeStamp){
mill=getNewTimeStamp();
}
returnmill;
}

privatelonggetNewTimeStamp(){
returnSystem.currentTimeMillis();
}

/**
*根據指定的資料中心ID和機器標誌ID生成指定的序列號
*
*@paramdataCenterId資料中心ID
*@parammachineId機器標誌ID
*/
publicSnowFlakeShortUrl(longdataCenterId,longmachineId){
if(dataCenterId>MAX_DATA_CENTER_NUM||dataCenterId<0){
thrownewIllegalArgumentException("DtaCenterId can't be greater than MAX_DATA_CENTER_NUM or less than 0！");
}
if(machineId>MAX_MACHINE_NUM||machineId<0){
thrownewIllegalArgumentException("MachineId can't be greater than MAX_MACHINE_NUM or less than 0！");
}
this.dataCenterId=dataCenterId;
this.machineId=machineId;
}

/**
*產生下一個ID
*
*@return
*/
publicsynchronizedlongnextId(){
longcurrTimeStamp=getNewTimeStamp();
if(currTimeStamp<lastTimeStamp){
thrownewRuntimeException("Clockmovedbackwards.Refusingtogenerateid");
}

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;//序列號部分
}

publicstaticvoidmain(String[]args){
SnowFlakeShortUrlsnowFlake=newSnowFlakeShortUrl(2,3);

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

7、百度（uid-generator）

uid-generator是由百度技術部開發，專案GitHub地址 https://github.com/baidu/uid-generatoruid-generator是基於Snowflake演算法實現的，與原始的snowflake演算法不同在於，uid-generator支援自定義時間戳、工作機器ID和序列號等各部分的位數，而且uid-generator中採用使用者自定義workId的生成策略。uid-generator需要與資料庫配合使用，需要新增一個WORKER_NODE表。當應用啟動時會向資料庫表中去插入一條資料，插入成功後返回的自增ID就是該機器的workId資料由host，port組成。對於uid-generatorID組成結構：workId，佔用了22個bit位，時間佔用了28個bit位，序列化佔用了13個bit位，需要注意的是，和原始的snowflake不太一樣，時間的單位是秒，而不是毫秒，workId也不一樣，而且同一應用每次重啟就會消費一個workId。

參考文獻
https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md

8、美團（Leaf）

Leaf由美團開發，github地址：https://github.com/Meituan-Dianping/LeafLeaf同時支援號段模式和snowflake演算法模式，可以切換使用。

號段模式

先匯入原始碼 https://github.com/Meituan-Dianping/Leaf ，在建一張表leaf_alloc

DROPTABLEIFEXISTS`leaf_alloc`;

CREATETABLE`leaf_alloc`(
`biz_tag`varchar(128)NOTNULLDEFAULT''COMMENT'業務key',
`max_id`bigint(20)NOTNULLDEFAULT'1'COMMENT'當前已經分配了的最大id',
`step`int(11)NOTNULLCOMMENT'初始步長，也是動態調整的最小步長',
`description`varchar(256)DEFAULTNULLCOMMENT'業務key的描述',
`update_time`timestampNOTNULLDEFAULTCURRENT_TIMESTAMPONUPDATECURRENT_TIMESTAMPCOMMENT'資料庫維護的更新時間',
PRIMARYKEY(`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

9、滴滴（Tinyid）

Tinyid由滴滴開發，Github地址：https://github.com/didi/tinyid。Tinyid是基於號段模式原理實現的與Leaf如出一轍，每個服務獲取一個號段（1000,2000]、（2000,3000]、（3000,4000]在這裡插入圖片描述
Tinyid提供http和tinyid-client兩種方式接入

Http方式接入

（1）匯入Tinyid原始碼：git clone https://github.com/didi/tinyid.git（2）建立資料表：

CREATETABLE`tiny_id_info`(
`id`bigint(20)unsignedNOTNULLAUTO_INCREMENTCOMMENT'自增主鍵',
`biz_type`varchar(63)NOTNULLDEFAULT''COMMENT'業務型別，唯一',
`begin_id`bigint(20)NOTNULLDEFAULT'0'COMMENT'開始id，僅記錄初始值，無其他含義。初始化時begin_id和max_id應相同',
`max_id`bigint(20)NOTNULLDEFAULT'0'COMMENT'當前最大id',
`step`int(11)DEFAULT'0'COMMENT'步長',
`delta`int(11)NOTNULLDEFAULT'1'COMMENT'每次id增量',
`remainder`int(11)NOTNULLDEFAULT'0'COMMENT'餘數',
`create_time`timestampNOTNULLDEFAULT'2010-01-0100:00:00'COMMENT'建立時間',
`update_time`timestampNOTNULLDEFAULT'2010-01-0100:00:00'COMMENT'更新時間',
`version`bigint(20)NOTNULLDEFAULT'0'COMMENT'版本號',
PRIMARYKEY(`id`),
UNIQUEKEY`uniq_biz_type`(`biz_type`)
)ENGINE=InnoDBAUTO_INCREMENT=1DEFAULTCHARSET=utf8COMMENT'id資訊表';

CREATETABLE`tiny_id_token`(
`id`int(11)unsignedNOTNULLAUTO_INCREMENTCOMMENT'自增id',
`token`varchar(255)NOTNULLDEFAULT''COMMENT'token',
`biz_type`varchar(63)NOTNULLDEFAULT''COMMENT'此token可訪問的業務型別標識',
`remark`varchar(255)NOTNULLDEFAULT''COMMENT'備註',
`create_time`timestampNOTNULLDEFAULT'2010-01-0100:00:00'COMMENT'建立時間',
`update_time`timestampNOTNULLDEFAULT'2010-01-0100:00:00'COMMENT'更新時間',
PRIMARYKEY(`id`)
)ENGINE=InnoDBAUTO_INCREMENT=1DEFAULTCHARSET=utf8COMMENT'token資訊表';

INSERTINTO`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-2123:52:58','2018-07-2223:19:27',1);

INSERTINTO`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-2123:52:58','2018-07-2300:39:24',3);


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

INSERTINTO`tiny_id_token`(`id`,`token`,`biz_type`,`remark`,`create_time`,`update_time`)
VALUES
(2,'0f673adf80504e2eaa552f5d791b644c','test_odd','1','2017-12-1416:36:46','2017-12-1416: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
Longid=TinyId.nextId("test");

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