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

前兩天有個朋友給我發(fā)信息吐槽最近面試：“四哥做院，年前我在公司受點委屈一沖動就裸辭了，然后現(xiàn)在疫情嚴重兩個多月還沒找到工作濒持，接了幾個視頻面試也都沒下文贰谣。好多面試官問完一個問題队橙，緊接著說還會其他解決方法嗎？能干活解決bug不就行了嗎？那還得會多少種方法贬芥？”

面試官應(yīng)該是對應(yīng)聘者的回答不太滿意，他想聽到一個他認為最優(yōu)的解決方案蜀备，其實這無可厚非删咱。同樣一個bug，能用一行代碼解決問題的人和用十行代碼解決問題的人奶赔，你會選哪個入職惋嚎？顯而易見的事情！所以看待問題還是要從多個角度出發(fā)站刑，每種方法都有各自的利弊另伍。

一、為什么要用分布式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 NULL default '',

? ? 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用完，再次向數(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 + 1 where 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_id 1 // 初始化自增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 final static long START_TIMESTAMP = 1480166465631L;

? ? /**

? ? * 每一部分占用的位數(shù)

? ? */

? ? private final static long SEQUENCE_BIT = 12;? //序列號占用的位數(shù)

? ? private final static long MACHINE_BIT = 5;? ? //機器標識占用的位數(shù)

? ? private final static long 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() {

? ? ? ? return System.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) {

? ? ? ? ? ? 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;

? ? }

? ? /**

? ? * 產(chǎn)生下一個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) {

? ? ? ? ? ? //相同毫秒內(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 = new SnowFlakeShortUrl(2, 3);

? ? ? ? for (int i = 0; i < (1 << 4); i++) {

? ? ? ? ? ? //10進制

? ? ? ? ? ? System.out.println(snowFlake.nextId());

? ? ? ? }

? ? }

}

7如捅、百度（uid-generator）

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

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-generator ID組成結(jié)構(gòu)：

workId讶舰，占用了22個bit位，時間占用了28個bit位需了，序列化占用了13個bit位跳昼，需要注意的是，和原始的snowflake不太一樣肋乍，時間的單位是秒鹅颊，而不是毫秒，workId也不一樣墓造，而且同一應(yīng)用每次重啟就會消費一個workId堪伍。

8锚烦、美團（Leaf）

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

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

號段模式

先導(dǎo)入源碼 github.com/Meituan-Dia… ，在建一張表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模式

eaf.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

9、滴滴（Tinyid）

Tinyid是基于號段模式原理實現(xiàn)的與Leaf如出一轍豁辉，每個服務(wù)獲取一個號段（1000,2000]令野、（2000,3000]、（3000,4000]

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

Http方式接入

（1）導(dǎo)入Tinyid源碼：

git clonegithub.com/didi/tinyid…

（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=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可訪問的業(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=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）配置數(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）操作

引入依賴

<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是在數(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ù)需求售碳。

今天就說這么多，如果本文對您有一點幫助绞呈，希望能得到您一個點贊??哦

您的認可才是我寫作的動力贸人！

作者;程序員內(nèi)點事

出處：https://juejin.im/post/5e48a9af6fb9a07cc200c203

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市佃声，隨后出現(xiàn)的幾起案子艺智，更是在濱河造成了極大的恐慌，老刑警劉巖圾亏，帶你破解...
    沈念sama閱讀 206,968評論 6贊 482
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件力惯，死亡現(xiàn)場離奇詭異碗誉，居然都是意外死亡，警方通過查閱死者的電腦和手機父晶，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,601評論 2贊 382
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門哮缺，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人甲喝，你說我怎么就攤上這事尝苇。” “怎么了埠胖？”我有些...
    開封第一講書人閱讀 153,220評論 0贊 344
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵糠溜，是天一觀的道長。 經(jīng)常有香客問我直撤，道長非竿，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 55,416評論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任谋竖，我火速辦了婚禮红柱，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘蓖乘。我一直安慰自己锤悄，他們只是感情好，可當我...
    茶點故事閱讀 64,425評論 5贊 374
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布嘉抒。 她就那樣靜靜地躺著零聚，像睡著了一般。 火紅的嫁衣襯著肌膚如雪些侍。 梳的紋絲不亂的頭發(fā)上隶症，一...
    開封第一講書人閱讀 49,144評論 1贊 285
  • 城市分裂傳說
    那天，我揣著相機與錄音岗宣，去河邊找鬼沿腰。 笑死，一個胖子當著我的面吹牛狈定，可吹牛的內(nèi)容都是我干的颂龙。 我是一名探鬼主播，決...
    沈念sama閱讀 38,432評論 3贊 401
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼纽什，長吁一口氣：“原來是場噩夢啊……” “哼措嵌！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起芦缰，我...
    開封第一講書人閱讀 37,088評論 0贊 261
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤企巢，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后让蕾，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體浪规，經(jīng)...
    沈念sama閱讀 43,586評論 1贊 300
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡或听，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,028評論 2贊 325
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了笋婿。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片誉裆。...
    茶點故事閱讀 38,137評論 1贊 334
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖缸濒，靈堂內(nèi)的尸體忽然破棺而出足丢，到底是詐尸還是另有隱情，我是刑警寧澤庇配，帶...
    沈念sama閱讀 33,783評論 4贊 324
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布斩跌，位于F島的核電站，受9級特大地震影響捞慌，放射性物質(zhì)發(fā)生泄漏耀鸦。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點故事閱讀 39,343評論 3贊 307
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一啸澡、第九天 我趴在偏房一處隱蔽的房頂上張望袖订。 院中可真熱鬧，春花似錦锻霎、人聲如沸著角。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,333評論 0贊 19
  • 一樁弒父案旋恼，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至奄容，卻和暖如春冰更，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背昂勒。 一陣腳步聲響...
    開封第一講書人閱讀 31,559評論 1贊 262
  • 情欲美人皮
    我被黑心中介騙來泰國打工蜀细， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人戈盈。 一個月前我還...
    沈念sama閱讀 45,595評論 2贊 355
  • 代替公主和親
    正文 我出身青樓奠衔，卻偏偏與公主長得像，于是被迫代替她去往敵國和親塘娶。 傳聞我的和親對象是個殘疾皇子归斤，可洞房花燭夜當晚...
    茶點故事閱讀 42,901評論 2贊 345