自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

一口氣說出9種分布式ID生成方式，面試官有點(diǎn)懵了

作者：佚名
數(shù)據(jù)庫(kù) MySQL 分布式
本文只是簡(jiǎn)單介紹一下每種分布式ID生成器，旨在給大家一個(gè)詳細(xì)學(xué)習(xí)的方向，每種生成方式都有它自己的優(yōu)缺點(diǎn)，具體如何使用還要看具體的業(yè)務(wù)需求。

前兩天公眾號(hào)有個(gè)粉絲給我留言吐槽最近面試：“四哥，年前我在公司受點(diǎn)委屈一沖動(dòng)就裸辭了，然后現(xiàn)在疫情嚴(yán)重兩個(gè)多月還沒找到工作，接了幾個(gè)視頻面試也都沒下文。好多面試官問完一個(gè)問題，緊接著說還會(huì)其他解決方法嗎？能干活解決bug不就行了嗎？那還得會(huì)多少種方法？”

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

一、為什么要用分布式ID？

在說分布式ID的具體實(shí)現(xiàn)之前，我們來簡(jiǎn)單分析一下為什么用分布式ID？分布式ID應(yīng)該滿足哪些特征？

1、什么是分布式ID？

拿MySQL數(shù)據(jù)庫(kù)舉個(gè)栗子：

在我們業(yè)務(wù)數(shù)據(jù)量不大的時(shí)候，單庫(kù)單表完全可以支撐現(xiàn)有業(yè)務(wù)，數(shù)據(jù)再大一點(diǎn)搞個(gè)MySQL主從同步讀寫分離也能對(duì)付。

但隨著數(shù)據(jù)日漸增長(zhǎng)，主從同步也扛不住了，就需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行分庫(kù)分表，但分庫(kù)分表后需要有一個(gè)唯一ID來標(biāo)識(shí)一條數(shù)據(jù)，數(shù)據(jù)庫(kù)的自增ID顯然不能滿足需求；特別一點(diǎn)的如訂單、優(yōu)惠券也都需要有唯一ID做標(biāo)識(shí)。此時(shí)一個(gè)能夠生成全局唯一ID的系統(tǒng)是非常必要的。那么這個(gè)全局唯一ID就叫分布式ID。

2、那么分布式ID需要滿足那些條件？

  •  全局唯一：必須保證ID是全局性唯一的，基本要求
  •  高性能：高可用低延時(shí)，ID生成響應(yīng)要塊，否則反倒會(huì)成為業(yè)務(wù)瓶頸
  •  高可用：100%的可用性是騙人的，但是也要無限接近于100%的可用性
  •  好接入：要秉著拿來即用的設(shè)計(jì)原則，在系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)上要盡可能的簡(jiǎn)單
  •  趨勢(shì)遞增：最好趨勢(shì)遞增，這個(gè)要求就得看具體業(yè)務(wù)場(chǎng)景了，一般不嚴(yán)格要求

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

今天主要分析一下以下9種，分布式ID生成器方式以及優(yōu)缺點(diǎn)：

  •  UUID
  •  數(shù)據(jù)庫(kù)自增ID
  •  數(shù)據(jù)庫(kù)多主模式
  •  號(hào)段模式
  •  Redis
  •  雪花算法（SnowFlake）
  •  滴滴出品（TinyID）
  •  百度 （Uidgenerator）
  •  美團(tuán)（Leaf）

那么它們都是如何實(shí)現(xiàn)？以及各自有什么優(yōu)缺點(diǎn)？我們往下看

圖片源自網(wǎng)絡(luò)

以上圖片源自網(wǎng)絡(luò)，如有侵權(quán)聯(lián)系刪除

1、基于UUID

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

  1. public static void main(String[] args) {   
  2.        String uuid = UUID.randomUUID().toString().replaceAll("-","");  
  3.        System.out.println(uuid); 
  4.   } 

UUID的生成簡(jiǎn)單到只有一行代碼，輸出結(jié)果 c2b8c2b9e46c47e3b30dca3b0d447718，但UUID卻并不適用于實(shí)際的業(yè)務(wù)需求。像用作訂單號(hào)UUID這樣的字符串沒有絲毫的意義，看不出和訂單相關(guān)的有用信息；而對(duì)于數(shù)據(jù)庫(kù)來說用作業(yè)務(wù)主鍵ID，它不僅是太長(zhǎng)還是字符串，存儲(chǔ)性能差查詢也很耗時(shí)，所以不推薦用作分布式ID。

優(yōu)點(diǎn)：

  •  生成足夠簡(jiǎn)單，本地生成無網(wǎng)絡(luò)消耗，具有唯一性

缺點(diǎn)：

  •  無序的字符串，不具備趨勢(shì)自增特性
  •  沒有具體的業(yè)務(wù)含義
  •  長(zhǎng)度過長(zhǎng)16 字節(jié)128位，36位長(zhǎng)度的字符串，存儲(chǔ)以及查詢對(duì)MySQL的性能消耗較大，MySQL官方明確建議主鍵要盡量越短越好，作為數(shù)據(jù)庫(kù)主鍵 UUID 的無序性會(huì)導(dǎo)致數(shù)據(jù)位置頻繁變動(dòng)，嚴(yán)重影響性能。

2、基于數(shù)據(jù)庫(kù)自增ID

基于數(shù)據(jù)庫(kù)的auto_increment自增ID完全可以充當(dāng)分布式ID，具體實(shí)現(xiàn)：需要一個(gè)單獨(dú)的MySQL實(shí)例用來生成ID，建表結(jié)構(gòu)如下： 

  1. CREATE DATABASE `SEQ_ID`;  
  2. CREATE TABLE SEQID.SEQUENCE_ID (  
  3.     id bigint(20) unsigned NOT NULL auto_increment,   
  4.     value char(10) NOT NULL default '',  
  5.     PRIMARY KEY (id),  
  6. ) ENGINE=MyISAM;  
  7. insert into SEQUENCE_ID(value)  VALUES ('values'); 

當(dāng)我們需要一個(gè)ID的時(shí)候，向表中插入一條記錄返回主鍵ID，但這種方式有一個(gè)比較致命的缺點(diǎn)，訪問量激增時(shí)MySQL本身就是系統(tǒng)的瓶頸，用它來實(shí)現(xiàn)分布式服務(wù)風(fēng)險(xiǎn)比較大，不推薦！

優(yōu)點(diǎn)：

  •  實(shí)現(xiàn)簡(jiǎn)單，ID單調(diào)自增，數(shù)值類型查詢速度快

缺點(diǎn)：

  •  DB單點(diǎn)存在宕機(jī)風(fēng)險(xiǎn)，無法扛住高并發(fā)場(chǎng)景

3、基于數(shù)據(jù)庫(kù)集群模式

前邊說了單點(diǎn)數(shù)據(jù)庫(kù)方式不可取，那對(duì)上邊的方式做一些高可用優(yōu)化，換成主從模式集群。害怕一個(gè)主節(jié)點(diǎn)掛掉沒法用，那就做雙主模式集群，也就是兩個(gè)Mysql實(shí)例都能單獨(dú)的生產(chǎn)自增ID。

那這樣還會(huì)有個(gè)問題，兩個(gè)MySQL實(shí)例的自增ID都從1開始，會(huì)生成重復(fù)的ID怎么辦？

解決方案：設(shè)置起始值和自增步長(zhǎng)

MySQL_1 配置： 

  1. set @@auto_increment_offset = 1;     -- 起始值  
  2. set @@auto_increment_increment = 2;  -- 步長(zhǎng) 

MySQL_2 配置： 

  1. set @@auto_increment_offset = 2;     -- 起始值  
  2. set @@auto_increment_increment = 2;  -- 步長(zhǎng) 

這樣兩個(gè)MySQL實(shí)例的自增ID分別就是：

1、3、5、7、9 

2、4、6、8、10

那如果集群后的性能還是扛不住高并發(fā)咋辦？就要進(jìn)行MySQL擴(kuò)容增加節(jié)點(diǎn)，這是一個(gè)比較麻煩的事。

在這里插入圖片描述

從上圖可以看出，水平擴(kuò)展的數(shù)據(jù)庫(kù)集群，有利于解決數(shù)據(jù)庫(kù)單點(diǎn)壓力的問題，同時(shí)為了ID生成特性，將自增步長(zhǎng)按照機(jī)器數(shù)量來設(shè)置。

增加第三臺(tái)MySQL實(shí)例需要人工修改一、二兩臺(tái)MySQL實(shí)例的起始值和步長(zhǎng)，把第三臺(tái)機(jī)器的ID起始生成位置設(shè)定在比現(xiàn)有最大自增ID的位置遠(yuǎn)一些，但必須在一、二兩臺(tái)MySQL實(shí)例ID還沒有增長(zhǎng)到第三臺(tái)MySQL實(shí)例的起始ID值的時(shí)候，否則自增ID就要出現(xiàn)重復(fù)了，必要時(shí)可能還需要停機(jī)修改。

優(yōu)點(diǎn)：

  •  解決DB單點(diǎn)問題

缺點(diǎn)：

  •  不利于后續(xù)擴(kuò)容，而且實(shí)際上單個(gè)數(shù)據(jù)庫(kù)自身壓力還是大，依舊無法滿足高并發(fā)場(chǎng)景。

4、基于數(shù)據(jù)庫(kù)的號(hào)段模式

號(hào)段模式是當(dāng)下分布式ID生成器的主流實(shí)現(xiàn)方式之一，號(hào)段模式可以理解為從數(shù)據(jù)庫(kù)批量的獲取自增ID，每次從數(shù)據(jù)庫(kù)取出一個(gè)號(hào)段范圍，例如 (1,1000] 代表1000個(gè)ID，具體的業(yè)務(wù)服務(wù)將本號(hào)段，生成1~1000的自增ID并加載到內(nèi)存。表結(jié)構(gòu)如下： 

  1. CREATE TABLE id_generator (  
  2.   id int(10) NOT NULL,  
  3.   max_id bigint(20) NOT NULL COMMENT '當(dāng)前最大id',  
  4.   step int(20) NOT NULL COMMENT '號(hào)段的布長(zhǎng)',  
  5.   biz_type    int(20) NOT NULL COMMENT '業(yè)務(wù)類型',  
  6.   version int(20) NOT NULL COMMENT '版本號(hào)',  
  7.   PRIMARY KEY (`id`)  
  8. )  

biz_type ：代表不同業(yè)務(wù)類型

max_id ：當(dāng)前最大的可用id

step ：代表號(hào)段的長(zhǎng)度

version ：是一個(gè)樂觀鎖，每次都更新version，保證并發(fā)時(shí)數(shù)據(jù)的正確性

id biz_type max_id step version
1 101 1000 2000 0

等這批號(hào)段ID用完，再次向數(shù)據(jù)庫(kù)申請(qǐng)新號(hào)段，對(duì)max_id字段做一次update操作，update max_id= max_id + step，update成功則說明新號(hào)段獲取成功，新的號(hào)段范圍是(max_id ,max_id +step]。 

  1. update id_generator set max_id = #{max_id+step}, versionversion = version + 1 where version = # {version} and biz_type = XXX 

由于多業(yè)務(wù)端可能同時(shí)操作，所以采用版本號(hào)version樂觀鎖方式更新，這種分布式ID生成方式不強(qiáng)依賴于數(shù)據(jù)庫(kù)，不會(huì)頻繁的訪問數(shù)據(jù)庫(kù)，對(duì)數(shù)據(jù)庫(kù)的壓力小很多。

5、基于Redis模式

Redis也同樣可以實(shí)現(xiàn)，原理就是利用redis的 incr命令實(shí)現(xiàn)ID的原子性自增。 

  1. 127.0.0.1:6379> set seq_id 1     // 初始化自增ID為1  
  2. OK  
  3. 127.0.0.1:6379> incr seq_id      // 增加1，并返回遞增后的數(shù)值 
  4. (integer) 2 

用redis實(shí)現(xiàn)需要注意一點(diǎn)，要考慮到redis持久化的問題。redis有兩種持久化方式RDB和AOF

  •  RDB會(huì)定時(shí)打一個(gè)快照進(jìn)行持久化，假如連續(xù)自增但redis沒及時(shí)持久化，而這會(huì)Redis掛掉了，重啟Redis后會(huì)出現(xiàn)ID重復(fù)的情況。
  •  AOF會(huì)對(duì)每條寫命令進(jìn)行持久化，即使Redis掛掉了也不會(huì)出現(xiàn)ID重復(fù)的情況，但由于incr命令的特殊性，會(huì)導(dǎo)致Redis重啟恢復(fù)的數(shù)據(jù)時(shí)間過長(zhǎng)。

6、基于雪花算法（Snowflake）模式

雪花算法（Snowflake）是twitter公司內(nèi)部分布式項(xiàng)目采用的ID生成算法，開源后廣受國(guó)內(nèi)大廠的好評(píng)，在該算法影響下各大公司相繼開發(fā)出各具特色的分布式生成器。

在這里插入圖片描述

以上圖片源自網(wǎng)絡(luò)，如有侵權(quán)聯(lián)系刪除

Snowflake生成的是Long類型的ID，一個(gè)Long類型占8個(gè)字節(jié)，每個(gè)字節(jié)占8比特，也就是說一個(gè)Long類型占64個(gè)比特。

Snowflake ID組成結(jié)構(gòu)：正數(shù)位（占1比特）+ 時(shí)間戳（占41比特）+ 機(jī)器ID（占5比特）+ 數(shù)據(jù)中心（占5比特）+ 自增值（占12比特），總共64比特組成的一個(gè)Long類型。

  •  第一個(gè)bit位（1bit）：Java中l(wèi)ong的最高位是符號(hào)位代表正負(fù)，正數(shù)是0，負(fù)數(shù)是1，一般生成ID都為正數(shù)，所以默認(rèn)為0。
  •  時(shí)間戳部分（41bit）：毫秒級(jí)的時(shí)間，不建議存當(dāng)前時(shí)間戳，而是用（當(dāng)前時(shí)間戳 - 固定開始時(shí)間戳）的差值，可以使產(chǎn)生的ID從更小的值開始；41位的時(shí)間戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
  •  工作機(jī)器id（10bit）：也被叫做workId，這個(gè)可以靈活配置，機(jī)房或者機(jī)器號(hào)組合都可以。
  •  序列號(hào)部分（12bit），自增值支持同一毫秒內(nèi)同一個(gè)節(jié)點(diǎn)可以生成4096個(gè)ID

根據(jù)這個(gè)算法的邏輯，只需要將這個(gè)算法用Java語(yǔ)言實(shí)現(xiàn)出來，封裝為一個(gè)工具方法，那么各個(gè)業(yè)務(wù)應(yīng)用可以直接使用該工具方法來獲取分布式ID，只需保證每個(gè)業(yè)務(wù)應(yīng)用有自己的工作機(jī)器id即可，而不需要單獨(dú)去搭建一個(gè)獲取分布式ID的應(yīng)用。

Java版本的Snowflake算法實(shí)現(xiàn)： 

  1. /**  
  2.  * Twitter的SnowFlake算法,使用SnowFlake算法生成一個(gè)整數(shù)，然后轉(zhuǎn)化為62進(jìn)制變成一個(gè)短地址URL  
  3.  *  
  4.  * https://github.com/beyondfengyu/SnowFlake  
  5.  */  
  6. public class SnowFlakeShortUrl {  
  7.     /**  
  8.      * 起始的時(shí)間戳  
  9.      */  
  10.     private final static long START_TIMESTAMP = 1480166465631L;  
  11.     /**  
  12.      * 每一部分占用的位數(shù)  
  13.      */  
  14.     private final static long SEQUENCE_BIT = 12;   //序列號(hào)占用的位數(shù)  
  15.     private final static long MACHINE_BIT = 5;     //機(jī)器標(biāo)識(shí)占用的位數(shù)  
  16.     private final static long DATA_CENTER_BIT = 5; //數(shù)據(jù)中心占用的位數(shù)  
  17.     /**  
  18.      * 每一部分的最大值  
  19.      */  
  20.     private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);  
  21.     private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);  
  22.     private final static long MAX_DATA_CENTER_NUM = -1L ^ (-1L << DATA_CENTER_BIT);  
  23.     /**  
  24.      * 每一部分向左的位移  
  25.      */  
  26.     private final static long MACHINE_LEFT = SEQUENCE_BIT;  
  27.     private final static long DATA_CENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;  
  28.     private final static long TIMESTAMP_LEFT = DATA_CENTER_LEFT + DATA_CENTER_BIT;  
  29.     private long dataCenterId;  //數(shù)據(jù)中心  
  30.     private long machineId;     //機(jī)器標(biāo)識(shí)  
  31.     private long sequence = 0L; //序列號(hào)  
  32.     private long lastTimeStamp = -1L;  //上一次時(shí)間戳  
  33.     private long getNextMill() {  
  34.         long mill = getNewTimeStamp();  
  35.         while (mill <= lastTimeStamp) {  
  36.             mill = getNewTimeStamp();  
  37.         }  
  38.         return mill;  
  39.     }  
  40.     private long getNewTimeStamp() {  
  41.         return System.currentTimeMillis();  
  42.     }  
  43.     /**  
  44.      * 根據(jù)指定的數(shù)據(jù)中心ID和機(jī)器標(biāo)志ID生成指定的序列號(hào)  
  45.      *  
  46.      * @param dataCenterId 數(shù)據(jù)中心ID  
  47.      * @param machineId    機(jī)器標(biāo)志ID  
  48.      */  
  49.     public SnowFlakeShortUrl(long dataCenterId, long machineId) {  
  50.         if (dataCenterId > MAX_DATA_CENTER_NUM || dataCenterId < 0) {  
  51.             throw new IllegalArgumentException("DtaCenterId can't be greater than MAX_DATA_CENTER_NUM or less than 0！");  
  52.         }  
  53.         if (machineId > MAX_MACHINE_NUM || machineId < 0) {  
  54.             throw new IllegalArgumentException("MachineId can't be greater than MAX_MACHINE_NUM or less than 0！");  
  55.         }  
  56.         this.dataCenterId = dataCenterId;  
  57.         this.machineId = machineId;  
  58.     }  
  59.     /**  
  60.      * 產(chǎn)生下一個(gè)ID  
  61.      *  
  62.      * @return  
  63.      */  
  64.     public synchronized long nextId() {  
  65.         long currTimeStamp = getNewTimeStamp();  
  66.         if (currTimeStamp < lastTimeStamp) { 
  67.              throw new RuntimeException("Clock moved backwards.  Refusing to generate id");  
  68.         }  
  69.         if (currTimeStamp == lastTimeStamp) {  
  70.             //相同毫秒內(nèi)，序列號(hào)自增  
  71.             sequence = (sequence + 1) & MAX_SEQUENCE;  
  72.             //同一毫秒的序列數(shù)已經(jīng)達(dá)到最大  
  73.             if (sequence == 0L) {  
  74.                 currTimeStamp = getNextMill();  
  75.             }  
  76.         } else {  
  77.             //不同毫秒內(nèi)，序列號(hào)置為0  
  78.             sequence = 0L;  
  79.         }  
  80.         lastTimeStamp = currTimeStamp;  
  81.         return (currTimeStamp - START_TIMESTAMP) << TIMESTAMP_LEFT //時(shí)間戳部分  
  82.                 | dataCenterId << DATA_CENTER_LEFT       //數(shù)據(jù)中心部分  
  83.                 | machineId << MACHINE_LEFT             //機(jī)器標(biāo)識(shí)部分  
  84.                 | sequence;                             //序列號(hào)部分  
  85.     }  
  86.     public static void main(String[] args) {  
  87.         SnowFlakeShortUrl snowFlake = new SnowFlakeShortUrl(2, 3);  
  88.         for (int i = 0; i < (1 << 4); i++) {  
  89.             //10進(jìn)制 
  90.              System.out.println(snowFlake.nextId());  
  91.         }  
  92.     }  
  93. } 

7、百度（uid-generator）

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

uid-generator是基于Snowflake算法實(shí)現(xiàn)的，與原始的snowflake算法不同在于，uid-generator支持自定義時(shí)間戳、工作機(jī)器ID和 序列號(hào) 等各部分的位數(shù)，而且uid-generator中采用用戶自定義workId的生成策略。

uid-generator需要與數(shù)據(jù)庫(kù)配合使用，需要新增一個(gè)WORKER_NODE表。當(dāng)應(yīng)用啟動(dòng)時(shí)會(huì)向數(shù)據(jù)庫(kù)表中去插入一條數(shù)據(jù)，插入成功后返回的自增ID就是該機(jī)器的workId數(shù)據(jù)由host，port組成。

對(duì)于uid-generator ID組成結(jié)構(gòu)：

workId，占用了22個(gè)bit位，時(shí)間占用了28個(gè)bit位，序列化占用了13個(gè)bit位，需要注意的是，和原始的snowflake不太一樣，時(shí)間的單位是秒，而不是毫秒，workId也不一樣，而且同一應(yīng)用每次重啟就會(huì)消費(fèi)一個(gè)workId。

參考文獻(xiàn)

https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md

8、美團(tuán)（Leaf）

Leaf由美團(tuán)開發(fā)，github地址：https://github.com/Meituan-Dianping/Leaf

Leaf同時(shí)支持號(hào)段模式和snowflake算法模式，可以切換使用。

號(hào)段模式

先導(dǎo)入源碼 https://github.com/Meituan-Dianping/Leaf ，在建一張表leaf_alloc 

  1. DROP TABLE IF EXISTS `leaf_alloc`;  
  2. CREATE TABLE `leaf_alloc` (  
  3.   `biz_tag` varchar(128)  NOT NULL DEFAULT '' COMMENT '業(yè)務(wù)key', 
  4.   `max_id` bigint(20) NOT NULL DEFAULT '1' COMMENT '當(dāng)前已經(jīng)分配了的最大id',  
  5.   `step` int(11) NOT NULL COMMENT '初始步長(zhǎng)，也是動(dòng)態(tài)調(diào)整的最小步長(zhǎng)',  
  6.   `description` varchar(256)  DEFAULT NULL COMMENT '業(yè)務(wù)key的描述',  
  7.   `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '數(shù)據(jù)庫(kù)維護(hù)的更新時(shí)間',  
  8.   PRIMARY KEY (`biz_tag`)  
  9. ) ENGINE=InnoDB; 

然后在項(xiàng)目中開啟號(hào)段模式，配置對(duì)應(yīng)的數(shù)據(jù)庫(kù)信息，并關(guān)閉snowflake模式 

  1. leaf.name=com.sankuai.leaf.opensource.test  
  2. leaf.segment.enable=true  
  3. leaf.jdbc.url=jdbc:mysql://localhost:3306/leaf_test?useUnicode=true&characterEncoding=utf8&characterSetResults=utf8  
  4. leaf.jdbc.username=root  
  5. leaf.jdbc.password=root  
  6. leaf.snowflake.enable=false  
  7. #leaf.snowflake.zk.address=  
  8. #leaf.snowflake.port= 

啟動(dòng)leaf-server 模塊的 LeafServerApplication項(xiàng)目就跑起來了

號(hào)段模式獲取分布式自增ID的測(cè)試url ：http：//localhost：8080/api/segment/get/leaf-segment-test

監(jiān)控號(hào)段模式：http://localhost:8080/cache

snowflake模式

Leaf的snowflake模式依賴于ZooKeeper，不同于原始snowflake算法也主要是在workId的生成上，Leaf中workId是基于ZooKeeper的順序Id來生成的，每個(gè)應(yīng)用在使用Leaf-snowflake時(shí)，啟動(dòng)時(shí)都會(huì)都在Zookeeper中生成一個(gè)順序Id，相當(dāng)于一臺(tái)機(jī)器對(duì)應(yīng)一個(gè)順序節(jié)點(diǎn)，也就是一個(gè)workId。 

  1. leaf.snowflake.enable=true  
  2. leaf.snowflake.zk.address=127.0.0.1  
  3. leaf.snowflake.port=2181 

snowflake模式獲取分布式自增ID的測(cè)試url：http://localhost:8080/api/snowflake/get/test

9、滴滴（Tinyid）

Tinyid由滴滴開發(fā)，Github地址：https://github.com/didi/tinyid。

Tinyid是基于號(hào)段模式原理實(shí)現(xiàn)的與Leaf如出一轍，每個(gè)服務(wù)獲取一個(gè)號(hào)段（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ù)表： 

  1. CREATE TABLE `tiny_id_info` (  
  2.   `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',  
  3.   `biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '業(yè)務(wù)類型，唯一',  
  4.   `begin_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '開始id，僅記錄初始值，無其他含義。初始化時(shí)begin_id和max_id應(yīng)相同',  
  5.   `max_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '當(dāng)前最大id',  
  6.   `step` int(11) DEFAULT '0' COMMENT '步長(zhǎng)',  
  7.   `delta` int(11) NOT NULL DEFAULT '1' COMMENT '每次id增量',  
  8.   `remainder` int(11) NOT NULL DEFAULT '0' COMMENT '余數(shù)',  
  9.   `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '創(chuàng)建時(shí)間',  
  10.   `update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新時(shí)間',  
  11.   `version` bigint(20) NOT NULL DEFAULT '0' COMMENT '版本號(hào)',  
  12.   PRIMARY KEY (`id`),  
  13.   UNIQUE KEY `uniq_biz_type` (`biz_type`)  
  14. ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'id信息表';   
  15. CREATE TABLE `tiny_id_token` (  
  16.   `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',  
  17.   `token` varchar(255) NOT NULL DEFAULT '' COMMENT 'token',  
  18.   `biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '此token可訪問的業(yè)務(wù)類型標(biāo)識(shí)',  
  19.   `remark` varchar(255) NOT NULL DEFAULT '' COMMENT '備注',  
  20.   `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '創(chuàng)建時(shí)間',  
  21.   `update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新時(shí)間',  
  22.   PRIMARY KEY (`id`)  
  23. ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'token信息表';  
  24. INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)  
  25. VALUES  
  26.     (1, 'test', 1, 1, 100000, 1, 0, '2018-07-21 23:52:58', '2018-07-22 23:19:27', 1);  
  27. INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)  
  28. VALUES  
  29.     (2, 'test_odd', 1, 1, 100000, 2, 1, '2018-07-21 23:52:58', '2018-07-23 00:39:24', 3);  
  30. INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`) 
  31. VALUES  
  32.     (1, '0f673adf80504e2eaa552f5d791b644c', 'test', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');  
  33. INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`)  
  34. VALUES  
  35.     (2, '0f673adf80504e2eaa552f5d791b644c', 'test_odd', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48'); 

（3）配置數(shù)據(jù)庫(kù)： 

  1. datasource.tinyid.names=primary  
  2. datasource.tinyid.primary.driver-class-name=com.mysql.jdbc.Driver  
  3. datasource.tinyid.primary.url=jdbc:mysql://ip:port/databaseName?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8  
  4. datasource.tinyid.primary.username=root  
  5. datasource.tinyid.primary.password=123456 

（4）啟動(dòng)tinyid-server后測(cè)試 

  1. 獲取分布式自增ID: http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c'  
  2. 返回結(jié)果: 3  
  3. 批量獲取分布式自增ID:  
  4. http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c&batchSize=10'  
  5. 返回結(jié)果:  4,5,6,7,8,9,10,11,12,13 

Java客戶端方式接入

重復(fù)Http方式的（2）（3）操作

引入依賴     

  1. <dependency>  
  2.           <groupId>com.xiaoju.uemc.tinyid</groupId>  
  3.           <artifactId>tinyid-client</artifactId>  
  4.           <version>${tinyid.version}</version>  
  5.       </dependency> 

配置文件 

  1. tinyid.server =localhost:9999  
  2. tinyid.token =0f673adf80504e2eaa552f5d791b644c 

test 、tinyid.token是在數(shù)據(jù)庫(kù)表中預(yù)先插入的數(shù)據(jù)，test 是具體業(yè)務(wù)類型，tinyid.token表示可訪問的業(yè)務(wù)類型 

  1. // 獲取單個(gè)分布式自增ID  
  2. Long id =  TinyId . nextId( " test " );  
  3. // 按需批量分布式自增ID  
  4. List< Long > ids =  TinyId . nextId( " test " , 10 ); 

總結(jié)

本文只是簡(jiǎn)單介紹一下每種分布式ID生成器，旨在給大家一個(gè)詳細(xì)學(xué)習(xí)的方向，每種生成方式都有它自己的優(yōu)缺點(diǎn)，具體如何使用還要看具體的業(yè)務(wù)需求。 

 

責(zé)任編輯：龐桂玉 來源： 數(shù)據(jù)庫(kù)開發(fā)
分布式ID數(shù)據(jù)庫(kù)MySQL
相關(guān)推薦

2020-11-04 14:20:58

分布式數(shù)據(jù)庫(kù)MySQL

2020-08-12 09:55:07

附近的人數(shù)據(jù)庫(kù)MySQL

2020-04-16 12:42:42

附近的人共享單車App

2020-09-24 09:08:04

分布式系統(tǒng)架構(gòu)

2020-07-10 07:44:26

Session方式Web

2021-12-06 08:30:49

SpringSpring Bean面試題

2020-05-08 10:08:21

延時(shí)隊(duì)列APIDelayQueue

2020-04-14 13:32:56

@Transacti失效場(chǎng)景

2020-03-31 08:12:25

Kafka架構(gòu)數(shù)據(jù)庫(kù)

2020-07-08 07:45:44

OAuth2.0授權(quán)

2022-05-24 11:50:46

延時(shí)消息分布式

2020-12-21 06:07:35

Mybatis設(shè)計(jì)模式

2022-08-19 19:19:32

分庫(kù)分表ID生成方案

2021-06-08 22:43:07

IPC方式Qt

2021-03-29 12:22:25

微信iOS蘋果

2024-02-22 17:02:09

IDUUID雪花算法

2023-12-18 23:09:25

開源優(yōu)化引擎

2020-10-22 12:30:33

MySQL

2024-03-26 09:42:27

分片算法應(yīng)用

2020-06-04 07:45:07

過濾器和攔截器
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)