分布式id的設計方案（一口氣說出9種分布式ID生成方式）

發布時間：2024-01-24閱讀(13)

導讀以下文章來源于程序員內點事，作者程序員內點事一、為什么要用分布式ID？在說分布式ID的具體實現之前，我們來簡單分析一下為什么用分布式ID？分布式ID應該滿足....

以下文章來源于程序員內點事，作者程序員內點事

一、為什么要用分布式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）

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

分布式id的設計方案（一口氣說出9種分布式ID生成方式）(1)

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

1、基于UUID

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

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

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

優點：

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

缺點：

無序的字符串，不具備趨勢自增特性
沒有具體的業務含義
長度過長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 ：當前最大的可用id
step ：代表號段的長度
version ：是一個樂觀鎖，每次都更新version，保證并發時數據的正確性
idbiz_typemax_idstepversion1101100020000
等這批號段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為1OK127.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 cant be greater than MAX_DATA_CENTER_NUM or less than 0！");}if(machineId>MAX_MACHINE_NUM||machineId<0){thrownewIllegalArgumentException("MachineId cant 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{//不同毫秒內，序列號置為0sequence=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-generator
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。
參考文獻https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md
8、美團（Leaf）
Leaf由美團開發，github地址：https://github.com/Meituan-Dianping/Leaf
Leaf同時支持號段模式和snowflake算法模式，可以切換使用。
號段模式
先導入源碼 https://github.com/Meituan-Dianping/Leaf ，在建一張表leaf_alloc
DROPTABLEIFEXISTS`leaf_alloc`;CREATETABLE`leaf_alloc`(`biz_tag`varchar(128)NOTNULLDEFAULTCOMMENT業務key,`max_id`bigint(20)NOTNULLDEFAULT1COMMENT當前已經分配了的最大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.testleaf.segment.enable=trueleaf.jdbc.url=jdbc:mysql://localhost:3306/leaf_test?useUnicode=true&characterEncoding=utf8&characterSetResults=utf8leaf.jdbc.username=rootleaf.jdbc.password=rootleaf.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=trueleaf.snowflake.zk.address=127.0.0.1leaf.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)NOTNULLDEFAULTCOMMENT業務類型，唯一,`begin_id`bigint(20)NOTNULLDEFAULT0COMMENT開始id，僅記錄初始值，無其他含義。初始化時begin_id和max_id應相同,`max_id`bigint(20)NOTNULLDEFAULT0COMMENT當前最大id,`step`int(11)DEFAULT0COMMENT步長,`delta`int(11)NOTNULLDEFAULT1COMMENT每次id增量,`remainder`int(11)NOTNULLDEFAULT0COMMENT余數,`create_time`timestampNOTNULLDEFAULT2010-01-0100:00:00COMMENT創建時間,`update_time`timestampNOTNULLDEFAULT2010-01-0100:00:00COMMENT更新時間,`version`bigint(20)NOTNULLDEFAULT0COMMENT版本號,PRIMARYKEY(`id`),UNIQUEKEY`uniq_biz_type`(`biz_type`))ENGINE=InnoDBAUTO_INCREMENT=1DEFAULTCHARSET=utf8COMMENTid信息表;CREATETABLE`tiny_id_token`(`id`int(11)unsignedNOTNULLAUTO_INCREMENTCOMMENT自增id,`token`varchar(255)NOTNULLDEFAULTCOMMENTtoken,`biz_type`varchar(63)NOTNULLDEFAULTCOMMENT此token可訪問的業務類型標識,`remark`varchar(255)NOTNULLDEFAULTCOMMENT備注,`create_time`timestampNOTNULLDEFAULT2010-01-0100:00:00COMMENT創建時間,`update_time`timestampNOTNULLDEFAULT2010-01-0100:00:00COMMENT更新時間,PRIMARYKEY(`id`))ENGINE=InnoDBAUTO_INCREMENT=1DEFAULTCHARSET=utf8COMMENTtoken信息表;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=primarydatasource.tinyid.primary.driver-class-name=com.mysql.jdbc.Driverdatasource.tinyid.primary.url=jdbc:mysql://ip:port/databaseName?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8datasource.tinyid.primary.username=rootdatasource.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:9999tinyid.token=0f673adf80504e2eaa552f5d791b644c
test 、tinyid.token是在數據庫表中預先插入的數據，test 是具體業務類型，tinyid.token表示可訪問的業務類型
//獲取單個分布式自增IDLongid=TinyId.nextId("test");//按需批量分布式自增IDList<Long>ids=TinyId.nextId("test",10);
總結
本文只是簡單介紹一下每種分布式ID生成器，旨在給大家一個詳細學習的方向，每種生成方式都有它自己的優缺點，具體如何使用還要看具體的業務需求。