一、為什么要用分布式ID？
????在說分布式ID的具體實現(xiàn)之前，我們來簡單分析一下為什么用分布式ID？分布式ID應(yīng)該滿足哪些特征？
? ??1、什么是分布式ID？
????拿MySQL數(shù)據(jù)庫舉個栗子：
????????在我們業(yè)務(wù)數(shù)據(jù)量不大的時候，單庫單表完全可以支撐現(xiàn)有業(yè)務(wù)，數(shù)據(jù)再大一點搞個MySQL主從同步讀寫分離也能對付。
????????但隨著數(shù)據(jù)日漸增長，主從同步也扛不住了，就需要對數(shù)據(jù)庫進行分庫分表，但分庫分表后需要有一個唯一ID來標識一條數(shù)據(jù)，數(shù)據(jù)庫的自增ID顯然不能滿足需求；特別一點的如訂單、優(yōu)惠券也都需要有唯一ID做標識。此時一個能夠生成全局唯一ID的系統(tǒng)是非常必要的。那么這個全局唯一ID就叫分布式ID。
????2、那么分布式ID需要滿足那些條件？
????????全局唯一：必須保證ID是全局性唯一的，基本要求
????????高性能：高可用低延時，ID生成響應(yīng)要塊，否則反倒會成為業(yè)務(wù)瓶頸
????????高可用：100%的可用性是騙人的，但是也要無限接近于100%的可用性
????????好接入：要秉著拿來即用的設(shè)計原則，在系統(tǒng)設(shè)計和實現(xiàn)上要盡可能的簡單
????????趨勢遞增：最好趨勢遞增，這個要求就得看具體業(yè)務(wù)場景了，一般不嚴格要求
二、 分布式ID都有哪些生成方式？
????今天主要分析一下以下9種，分布式ID生成器方式以及優(yōu)缺點：
? ? -- UUID
? ? -- 數(shù)據(jù)庫自增ID
? ? -- 數(shù)據(jù)庫多主模式
? ? -- 號段模式
? ? -- Redis
? ? -- 雪花算法（SnowFlake）
? ? -- 滴滴出品（TinyID）
? ? -- 百度 （Uidgenerator）
? ? -- 美團（Leaf）
那么它們都是如何實現(xiàn)？以及各自有什么優(yōu)缺點？我們往下看
? ??1、基于UUID
? ? 在Java的世界里，想要得到一個具有唯一性的ID，首先被想到可能就是UUID，畢竟它有著全球唯一的特性。那么UUID可以做分布式ID嗎？答案是可以的，但是并不推薦！
????public static void main (String[]?args)?{
????????String uuid?=?UUID.randomUUID().toString().replaceAll("-","");
????????System.out.println(uuid);
????}
????UUID的生成簡單到只有一行代碼，輸出結(jié)果c2b8c2b9e46c47e3b30dca3b0d447718，但UUID卻并不適用于實際的業(yè)務(wù)需求。像用作訂單號UUID這樣的字符串沒有絲毫的意義，看不出和訂單相關(guān)的有用信息；而對于數(shù)據(jù)庫來說用作業(yè)務(wù)主鍵ID，它不僅是太長還是字符串，存儲性能差查詢也很耗時，所以不推薦用作分布式ID。
? ??優(yōu)點：
????????生成足夠簡單，本地生成無網(wǎng)絡(luò)消耗，具有唯一性
? ??缺點：
????????無序的字符串，不具備趨勢自增特性
????????沒有具體的業(yè)務(wù)含義
????長度過長16 字節(jié)128位，36位長度的字符串，存儲以及查詢對MySQL的性能消耗較大，MySQL官方明確建議主鍵要盡量越短越好，作為數(shù)據(jù)庫主鍵UUID的無序性會導(dǎo)致數(shù)據(jù)位置頻繁變動，嚴重影響性能。
????2、基于數(shù)據(jù)庫自增ID
????基于數(shù)據(jù)庫的auto_increment自增ID完全可以充當分布式ID，具體實現(xiàn)：需要一個單獨的MySQL實例用來生成ID，建表結(jié)構(gòu)如下：
????CREATE?DATABASE`SEQ_ID`;
????CREATE?TABLE?SEQID.SEQUENCE_ID?(
????????id?bigint(20)?unsigned?NOT?NULL?auto_increment,
????????value?char(10)?NOT?NULLdefault'',
????????PRIMARY?KEY?(id),
????)?ENGINE=MyISAM;
????insert?into?SEQUENCE_ID(value)??VALUES?('values');
????當我們需要一個ID的時候，向表中插入一條記錄返回主鍵ID，但這種方式有一個比較致命的缺點，訪問量激增時MySQL本身就是系統(tǒng)的瓶頸，用它來實現(xiàn)分布式服務(wù)風(fēng)險比較大，不推薦！
? ??優(yōu)點：
????????實現(xiàn)簡單，ID單調(diào)自增，數(shù)值類型查詢速度快
? ??缺點：
????????DB單點存在宕機風(fēng)險，無法扛住高并發(fā)場景
3、基于數(shù)據(jù)庫集群模式
????前邊說了單點數(shù)據(jù)庫方式不可取，那對上邊的方式做一些高可用優(yōu)化，換成主從模式集群。害怕一個主節(jié)點掛掉沒法用，那就做雙主模式集群，也就是兩個Mysql實例都能單獨的生產(chǎn)自增ID。
????那這樣還會有個問題，兩個MySQL實例的自增ID都從1開始，會生成重復(fù)的ID怎么辦？
? ??解決方案：設(shè)置起始值和自增步長
????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
????那如果集群后的性能還是扛不住高并發(fā)咋辦？就要進行MySQL擴容增加節(jié)點，這是一個比較麻煩的事。
????從上圖可以看出，水平擴展的數(shù)據(jù)庫集群，有利于解決數(shù)據(jù)庫單點壓力的問題，同時為了ID生成特性，將自增步長按照機器數(shù)量來設(shè)置。
????增加第三臺MySQL實例需要人工修改一、二兩臺MySQL實例的起始值和步長，把第三臺機器的ID起始生成位置設(shè)定在比現(xiàn)有最大自增ID的位置遠一些，但必須在一、二兩臺MySQL實例ID還沒有增長到第三臺MySQL實例的起始ID值的時候，否則自增ID就要出現(xiàn)重復(fù)了，必要時可能還需要停機修改。
? ??優(yōu)點：
????????解決DB單點問題
? ??缺點：
????????不利于后續(xù)擴容，而且實際上單個數(shù)據(jù)庫自身壓力還是大，依舊無法滿足高并發(fā)場景。
4、基于數(shù)據(jù)庫的號段模式
????號段模式是當下分布式ID生成器的主流實現(xiàn)方式之一，號段模式可以理解為從數(shù)據(jù)庫批量的獲取自增ID，每次從數(shù)據(jù)庫取出一個號段范圍，例如 (1,1000] 代表1000個ID，具體的業(yè)務(wù)服務(wù)將本號段，生成1~1000的自增ID并加載到內(nèi)存。表結(jié)構(gòu)如下：
????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'業(yè)務(wù)類型',
????????version?int(20)?NOT?NULL?COMMENT'版本號',
????????PRIMARY?KEY?(`id`)
????)
????biz_type ：代表不同業(yè)務(wù)類型
????max_id ：當前最大的可用id
????step ：代表號段的長度
????version ：是一個樂觀鎖，每次都更新version，保證并發(fā)時數(shù)據(jù)的正確性
? ? id? ? ?biz_type? ?max_id? ? step? ? ?version
????1? ? ? 10? ? ? ? ? ? 11000? ? ?2000? ? ? 0
????等這批號段ID用完，再次向數(shù)據(jù)庫申請新號段，對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?+1where?version?=?#?{version}?and?biz_type?=?XXX
????由于多業(yè)務(wù)端可能同時操作，所以采用版本號version樂觀鎖方式更新，這種分布式ID生成方式不強依賴于數(shù)據(jù)庫，不會頻繁的訪問數(shù)據(jù)庫，對數(shù)據(jù)庫的壓力小很多。
5、基于Redis模式
????Redis也同樣可以實現(xiàn)，原理就是利用redis的incr命令實現(xiàn)ID的原子性自增。
????127.0.0.1:6379>?set?seq_id1//?初始化自增ID為1
????OK
????127.0.0.1:6379>?incr?seq_id//?增加1，并返回遞增后的數(shù)值
????(integer)2
????用redis實現(xiàn)需要注意一點，要考慮到redis持久化的問題。redis有兩種持久化方式RDB和AOF
????RDB會定時打一個快照進行持久化，假如連續(xù)自增但redis沒及時持久化，而這會Redis掛掉了，重啟Redis后會出現(xiàn)ID重復(fù)的情況。
????AOF會對每條寫命令進行持久化，即使Redis掛掉了也不會出現(xiàn)ID重復(fù)的情況，但由于incr命令的特殊性，會導(dǎo)致Redis重啟恢復(fù)的數(shù)據(jù)時間過長。
6、基于雪花算法（Snowflake）模式
????雪花算法（Snowflake）是twitter公司內(nèi)部分布式項目采用的ID生成算法，開源后廣受國內(nèi)大廠的好評，在該算法影響下各大公司相繼開發(fā)出各具特色的分布式生成器。
????Snowflake生成的是Long類型的ID，一個Long類型占8個字節(jié)，每個字節(jié)占8比特，也就是說一個Long類型占64個比特。
????Snowflake ID組成結(jié)構(gòu)：正數(shù)位（占1比特）+時間戳（占41比特）+機器ID（占5比特）+數(shù)據(jù)中心（占5比特）+自增值（占12比特），總共64比特組成的一個Long類型。
????第一個bit位（1bit）：Java中l(wèi)ong的最高位是符號位代表正負，正數(shù)是0，負數(shù)是1，一般生成ID都為正數(shù)，所以默認為0。
????時間戳部分（41bit）：毫秒級的時間，不建議存當前時間戳，而是用（當前時間戳 - 固定開始時間戳）的差值，可以使產(chǎn)生的ID從更小的值開始；41位的時間戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
????工作機器id（10bit）：也被叫做workId，這個可以靈活配置，機房或者機器號組合都可以。
????序列號部分（12bit），自增值支持同一毫秒內(nèi)同一個節(jié)點可以生成4096個ID
????根據(jù)這個算法的邏輯，只需要將這個算法用Java語言實現(xiàn)出來，封裝為一個工具方法，那么各個業(yè)務(wù)應(yīng)用可以直接使用該工具方法來獲取分布式ID，只需保證每個業(yè)務(wù)應(yīng)用有自己的工作機器id即可，而不需要單獨去搭建一個獲取分布式ID的應(yīng)用。
Java版本的Snowflake算法實現(xiàn)：
/**
*?Twitter的SnowFlake算法,使用SnowFlake算法生成一個整數(shù)，然后轉(zhuǎn)化為62進制變成一個短地址URL
*
*?https://github.com/beyondfengyu/SnowFlake
*/
public class SnowFlakeShortUrl {
????/**
????*?起始的時間戳
????*/
????private?finalstaticlong?START_TIMESTAMP?=1480166465631L;
????/**
????*?每一部分占用的位數(shù)
????*/
????private?finalstaticlong?SEQUENCE_BIT?=12;//序列號占用的位數(shù)
????private?finalstaticlong?MACHINE_BIT?=5;//機器標識占用的位數(shù)
????private?finalstaticlong?DATA_CENTER_BIT?=5;//數(shù)據(jù)中心占用的位數(shù)
????/**
????*?每一部分的最大值
????*/
????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;//數(shù)據(jù)中心
????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()?{
????????returnSystem.currentTimeMillis();
????}
????/**
????*?根據(jù)指定的數(shù)據(jù)中心ID和機器標志ID生成指定的序列號
????*
????*?@param?dataCenterId?數(shù)據(jù)中心ID
????*?@param?machineId????機器標志ID
????*/
????public?SnowFlakeShortUrl(long?dataCenterId,?long?machineId)?{
????????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;
????}
????/**
????*?產(chǎn)生下一個ID
????*
????*?@return
????*/
????public?synchronized?long?nextId()?{
????????long?currTimeStamp?=?getNewTimeStamp();
????????if(currTimeStamp?<?lastTimeStamp)?{
????????????thrownewRuntimeException("Clock?moved?backwards.??Refusing?to?generate?id");
????????}
????????if (currTimeStamp?==?lastTimeStamp)?{
????????????//相同毫秒內(nèi)，序列號自增
???????????sequence?=?(sequence?+1)?&?MAX_SEQUENCE;
????????????//同一毫秒的序列數(shù)已經(jīng)達到最大
????????????if(sequence?==0L)?{
????????????????currTimeStamp?=?getNextMill();
????????????}
????????} else {
????????????//不同毫秒內(nèi)，序列號置為0
????????????sequence?=0L;
????????}
????????lastTimeStamp?=?currTimeStamp;
????????return(currTimeStamp?-?START_TIMESTAMP)?<<?TIMESTAMP_LEFT//時間戳部分
????????|?dataCenterId?<<?DATA_CENTER_LEFT//數(shù)據(jù)中心部分
????????|?machineId?<<?MACHINE_LEFT//機器標識部分
????????|?sequence;//序列號部分
????}
????public static void main(String[]?args)?{
????????SnowFlakeShortUrl?snowFlake?=newSnowFlakeShortUrl(2,3);
????????for(int?i?=0;?i?<?(1<<4);?i++)?{
????????//10進制
????????System.out.println(snowFlake.nextId());
????}
}
}
7、百度（uid-generator）
????uid-generator是由百度技術(shù)部開發(fā)，項目GitHub地址 https://github.com/baidu/uid-generator
????uid-generator是基于Snowflake算法實現(xiàn)的，與原始的snowflake算法不同在于，uid-generator支持自定義時間戳、工作機器ID和序列號等各部分的位數(shù)，而且uid-generator中采用用戶自定義workId的生成策略。
????uid-generator需要與數(shù)據(jù)庫配合使用，需要新增一個WORKER_NODE表。當應(yīng)用啟動時會向數(shù)據(jù)庫表中去插入一條數(shù)據(jù)，插入成功后返回的自增ID就是該機器的workId數(shù)據(jù)由host，port組成。
對于uid-generatorID組成結(jié)構(gòu)：
????workId，占用了22個bit位，時間占用了28個bit位，序列化占用了13個bit位，需要注意的是，和原始的snowflake不太一樣，時間的單位是秒，而不是毫秒，workId也不一樣，而且同一應(yīng)用每次重啟就會消費一個workId。
參考文獻
https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md
8、美團（Leaf）
????Leaf由美團開發(fā)，github地址：https://github.com/Meituan-Dianping/Leaf
????Leaf同時支持號段模式和snowflake算法模式，可以切換使用。
????號段模式
????先導(dǎo)入源碼?https://github.com/Meituan-Dianping/Leaf?，在建一張表leaf_alloc
????DROP?TABLE?IF?EXISTS`leaf_alloc`;
????CREATE?TABLE`leaf_alloc`(
????????`biz_tag`varchar(128)??NOT?NULL?DEFAULT''COMMENT'業(yè)務(wù)key',
????????`max_id`bigint(20)?NOT?NULL?DEFAULT'1'COMMENT'當前已經(jīng)分配了的最大id',
????????`step`int(11)?NOT?NULL?COMMENT'初始步長，也是動態(tài)調(diào)整的最小步長',
????????`description`varchar(256)??DEFAULT?NULL?COMMENT'業(yè)務(wù)key的描述',
????????`update_time`timestamp?NOT?NULL?DEFAULT?CURRENT_TIMESTAMP?ON?UPDATE?CURRENT_TIMESTAMP?COMMENT'數(shù)據(jù)庫維護的更新時間',
????????PRIMARY?KEY?(`biz_tag`)
????)?ENGINE=InnoDB;
????然后在項目中開啟號段模式，配置對應(yīng)的數(shù)據(jù)庫信息，并關(guān)閉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
????監(jiān)控號段模式：http://localhost:8080/cache
????snowflake模式
????Leaf的snowflake模式依賴于ZooKeeper，不同于原始snowflake算法也主要是在workId的生成上，Leaf中workId是基于ZooKeeper的順序Id來生成的，每個應(yīng)用在使用Leaf-snowflake時，啟動時都會都在Zookeeper中生成一個順序Id，相當于一臺機器對應(yīng)一個順序節(jié)點，也就是一個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由滴滴開發(fā)，Github地址：https://github.com/didi/tinyid。
????Tinyid是基于號段模式原理實現(xiàn)的與Leaf如出一轍，每個服務(wù)獲取一個號段（1000,2000]、（2000,3000]、（3000,4000]
????在這里插入圖片描述
????Tinyid提供http和tinyid-client兩種方式接入
????Http方式接入
????（1）導(dǎo)入Tinyid源碼：
????????git clone?https://github.com/didi/tinyid.git
????（2）創(chuàng)建數(shù)據(jù)表：
????CREATE?TABLE`tiny_id_info`(
????????`id`bigint(20)?unsigned?NOT?NULL?AUTO_INCREMENT?COMMENT'自增主鍵',
????????`biz_type`varchar(63)?NOT?NULL?DEFAULT''COMMENT'業(yè)務(wù)類型，唯一',
????????`begin_id`bigint(20)?NOT?NULL?DEFAULT'0'COMMENT'開始id，僅記錄初始值，無其他含義。初始化時begin_id和max_id應(yīng)相同',
????????`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'余數(shù)',
????????`create_time`timestamp?NOT?NULL?DEFAULT'2010-01-01?00:00:00'COMMENT'創(chuàng)建時間',
????????`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=1DEFAULT?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可訪問的業(yè)務(wù)類型標識',
????????`remark`varchar(255)?NOT?NULL?DEFAULT''COMMENT'備注',
????????`create_time`timestamp?NOT?NULL?DEFAULT'2010-01-01?00:00:00'COMMENT'創(chuàng)建時間',
????????`update_time`timestamp?NOT?NULL?DEFAULT'2010-01-01?00:00:00'COMMENT'更新時間',
????????PRIMARY?KEY?(`id`)
????)?ENGINE=InnoDB?AUTO_INCREMENT=1DEFAULT?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）配置數(shù)據(jù)庫：
????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'
????返回結(jié)果:3
????批量獲取分布式自增ID:
????http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c&batchSize=10'
????返回結(jié)果:4,5,6,7,8,9,10,11,12,13
????Java客戶端方式接入
????重復(fù)Http方式的（2）（3）操作
????引入依賴
????com.xiaoju.uemc.tinyid
????tinyid-client
????${tinyid.version}</
????version>
????配置文件
????tinyid.server?=localhost:9999
????tinyid.token?=0f673adf80504e2eaa552f5d791b644c
????test、tinyid.token是在數(shù)據(jù)庫表中預(yù)先插入的數(shù)據(jù)，test是具體業(yè)務(wù)類型，tinyid.token表示可訪問的業(yè)務(wù)類型
????//?獲取單個分布式自增ID
????Long?id?=??TinyId?.?nextId("?test?");
????//?按需批量分布式自增ID
????List<?Long?>?ids?=??TinyId?.?nextId("?test?",10);
????總結(jié)
????本文只是簡單介紹一下每種分布式ID生成器，旨在給大家一個詳細學(xué)習(xí)的方向，每種生成方式都有它自己的優(yōu)缺點，具體如何使用還要看具體的業(yè)務(wù)需求。
【本文轉(zhuǎn)載自 作者程序員內(nèi)點事】
