java面試之分布式ID

1. 分布式ID

業務資料量不大時，單庫單表完全可以支撐現有業務，資料再大一點MySQL主從同步讀寫分離也能應對。

随着資料日漸增長，需要對資料庫進行分庫分表，分庫分表後需要有一個唯一ID來辨別一條資料，此時一個能夠生成

全局唯一ID

的系統是非常必要的。那麼這個

全局唯一ID

就叫

分布式ID

。

全局唯一：必須保證ID是全局性唯一的
高性能：高可用低延時，ID生成響應要塊
好接入：秉着拿來即用的設計原則，在設計和實作上要盡可能簡單
高可用

2.分布式ID生成方式

java面試之分布式ID

UUID

原理：結合機器的網卡、當地時間、一個随記數來生成UUID。

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

優點：生成足夠簡單，本地生成無網絡消耗，時延低，性能高

缺點：沒有具體業務含義、存儲以及查詢效率低

基于資料庫自增ID

原理：使用資料庫的id自增政策，如 MySQL 的 auto_increment。

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單調自增，數值類型查詢速度快

缺點：DB單點存在當機風險，無法扛住高并發場景

資料庫叢集模式

雙主模式叢集，兩個Mysql執行個體都能單獨的生産自增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

水準擴充的資料庫叢集，有利于解決資料庫單點壓力問題，同時為了ID生成特性，将自增步長按照機器數量來設定。進行MySQL擴容增加節點，這是一個比較麻煩的事。

優點：解決DB單點問題

缺點：不利于後續擴容，而且實際上單個資料庫自身壓力還是大，依舊無法滿足高并發場景。

資料庫的号段模式

号段模式是當下分布式ID生成器的主流實作方式之一，号段模式可以了解為從資料庫批量的擷取自增ID，每次從資料庫擷取ID時，就擷取一個号段，如(1,1000]，這個範圍表示1000個ID，業務應用在請求提供ID時，隻需要在本地從1開始自增并傳回，而不需要每次去請求資料庫，一直到本地自增到1000。

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 '業務類型',
  # 一個樂觀鎖，每次都更新version，保證并發時資料正确性
  version int(20) NOT NULL COMMENT '版本号',
  PRIMARY KEY (`id`)
)

等這批号段ID用完，再次向資料庫申請新号段，對

max_id

字段做一次

update

操作，

update max_id= max_id + step

，update成功則說明新号段擷取成功，新的号段範圍是

(max_id ,max_id +step]

。由于多業務端可能同時操作，是以采用版本号

version

樂觀鎖方式更新。

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

Redis模式

原理：利用

redis

的

incr

指令實作ID的原子性自增。

127.0.0.1:6379> set seq_id 1     // 初始化自增ID為1
OK
127.0.0.1:6379> incr seq_id      // 增加1，并傳回遞增後的數值
(integer) 2

用

redis

實作需要注意一點，要考慮到redis持久化問題。

redis

有兩種持久化方式

RDB

和

AOF

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

優點：不依賴于資料庫，靈活友善；數字ID天然排序

缺點：增加系統複雜度

雪花算法

雪花算法（Snowflake）是twitter公司内部分布式項目采用的ID生成算法，在該算法影響下各大公司相繼開發出各具特色的分布式生成器。

Snowflake ID組成結構：

正數位

（占1比特）+

時間戳

（占41比特）+

機器ID

（占5比特）+

資料中心

（占5比特）+

自增值

（占12比特），總共64比特組成一個Long類型。

第一個位（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

下面給出一個業務場景：

服務目前QPS10萬，預計幾年之内會發展到百萬。
目前機器三地部署，上海，北京，深圳都有。
目前機器10台左右，預計未來會增加至百台。

java面試之分布式ID

應用

/**
 * Twitter的SnowFlake算法,使用SnowFlake算法生成一個整數，然後轉化為62進制變成一個短位址URL
 * https://github.com/beyondfengyu/SnowFlake
 */
public class SnowFlakeShortUrl {

    /**
     * 起始的時間戳
     */
    private final static long START_TIMESTAMP = 1480166465631L;

    /**
     * 每一部分占用的位數
     */
    private final static long SEQUENCE_BIT = 12;   //序列号占用的位數
    private final static long MACHINE_BIT = 5;     //機器辨別占用的位數
    private final static long DATA_CENTER_BIT = 5; //資料中心占用的位數

    /**
     * 每一部分的最大值
     */
    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;  //資料中心
    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();
    }

    /**
     * 根據指定的資料中心ID和機器标志ID生成指定的序列号
     *
     * @param dataCenterId 資料中心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;
    }

    /**
     * 産生下一個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) {
            //相同毫秒内，序列号自增
            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;                             //序列号部分
    }
    
    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());
        }
    }
}

優點：性能高，每秒可生成幾百萬ID；根據自身業務需求靈活調整bit位劃分

缺點：完全依賴于時間，如果時鐘回撥發生，會生成重複ID

Uid-generator

uid-generator

是由百度技術部開發，項目GitHub位址 https://github.com/baidu/uid-generator

64 bits的唯一ID

sign(1bit) 固定1bit符号辨別，即生成的UID為正數。
delta seconds (28 bits) 目前時間，相對于時間基點"2016-05-20"的增量值，機關：秒，最多可支援約8.7年
worker id (22 bits) 機器id，最多可支援約420w次機器啟動。内置實作為在啟動時由資料庫配置設定，預設配置設定政策為用後即棄，後續可提供複用政策。
sequence (13 bits) 每秒下的并發序列，13 bits可支援每秒8192個并發。

uid-generator

支援自

定義時間戳

、

工作機器ID

和

序列号

等各部分的位數，而且

uid-generator

中采用使用者自定義

workId

的生成政策。

uid-generator

需要與資料庫配合使用，需要新增一個

WORKER_NODE

表。當應用啟動時會向資料庫表中去插入一條資料，插入成功後傳回的自增ID就是該機器的

workId

資料由host，port組成。

DROP TABLE IF EXISTS WORKER_NODE;
CREATE TABLE WORKER_NODE(
  ID BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
  HOST_NAME VARCHAR(64) NOT NULL COMMENT 'host name',
  PORT VARCHAR(64) NOT NULL COMMENT 'port',
  TYPE INT NOT NULL COMMENT 'node type: ACTUAL or CONTAINER',
  LAUNCH_DATE DATE NOT NULL COMMENT 'launch date',
  MODIFIED DATETIME NOT NULL COMMENT 'modified time',
  CREATED DATEIMTE NOT NULL COMMENT 'created time'
)
 COMMENT='DB WorkerID Assigner for UID Generator',ENGINE = INNODB;

提供了兩種生成器: DefaultUidGenerator、CachedUidGenerator。如對UID生成性能有要求, 請使用CachedUidGenerator。

<!-- DefaultUidGenerator -->
<bean id="defaultUidGenerator" class="com.baidu.fsg.uid.impl.DefaultUidGenerator" lazy-init="false">
    <property name="workerIdAssigner" ref="disposableWorkerIdAssigner"/>

    <!-- Specified bits & epoch as your demand. No specified the default value will be used -->
    <property name="timeBits" value="29"/>
    <property name="workerBits" value="21"/>
    <property name="seqBits" value="13"/>
    <property name="epochStr" value="2016-09-20"/>
</bean>
 
<!-- 用完即棄的WorkerIdAssigner，依賴DB操作 -->
<bean id="disposableWorkerIdAssigner" class="com.baidu.fsg.uid.worker.DisposableWorkerIdAssigner" />

<!-- CachedUidGenerator -->
<bean id="cachedUidGenerator" class="com.baidu.fsg.uid.impl.CachedUidGenerator">
    <property name="workerIdAssigner" ref="disposableWorkerIdAssigner" />
 
    <!-- 以下為可選配置, 如未指定将采用預設值 -->
    <!-- Specified bits & epoch as your demand. No specified the default value will be used -->
    <property name="timeBits" value="29"/>
    <property name="workerBits" value="21"/>
    <property name="seqBits" value="13"/>
    <property name="epochStr" value="2016-09-20"/>
 
    <!-- RingBuffer size擴容參數, 可提高UID生成的吞吐量. -->
    <!-- 預設:3， 原bufferSize=8192, 擴容後bufferSize= 8192 << 3 = 65536 -->
    <property name="boostPower" value="3"></property>
 
    <!-- 指定何時向RingBuffer中填充UID, 取值為百分比(0, 100), 預設為50 -->
    <!-- 舉例: bufferSize=1024, paddingFactor=50 -> threshold=1024 * 50 / 100 = 512. -->
    <!-- 當環上可用UID數量 < 512時, 将自動對RingBuffer進行填充補全 -->
    <property name="paddingFactor" value="50"></property>
 
    <!-- 另外一種RingBuffer填充時機, 在Schedule線程中, 周期性檢查填充 -->
    <!-- 預設:不配置此項, 即不實用Schedule線程. 如需使用, 請指定Schedule線程時間間隔, 機關:秒 -->
    <property name="scheduleInterval" value="60"></property>
 
    <!-- 拒絕政策: 當環已滿, 無法繼續填充時 -->
    <!-- 預設無需指定, 将丢棄Put操作, 僅日志記錄. 如有特殊需求, 請實作RejectedPutBufferHandler接口(支援Lambda表達式) -->
    <property name="rejectedPutBufferHandler" ref="XxxxYourPutRejectPolicy"></property>
 
    <!-- 拒絕政策: 當環已空, 無法繼續擷取時 -->
    <!-- 預設無需指定, 将記錄日志, 并抛出UidGenerateException異常. 如有特殊需求, 請實作RejectedTakeBufferHandler接口(支援Lambda表達式) -->
    <property name="rejectedTakeBufferHandler" ref="XxxxYourTakeRejectPolicy"></property>
 
</bean>
 
<!-- 用完即棄的WorkerIdAssigner, 依賴DB操作 -->
<bean id="disposableWorkerIdAssigner" class="com.baidu.fsg.uid.worker.DisposableWorkerIdAssigner" />

<!-- Mybatis配置 Spring annotation掃描 -->
<context:component-scan base-package="com.baidu.fsg.uid" />

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
    <property name="dataSource" ref="dataSource" />
    <property name="mapperLocations" value="classpath:/META-INF/mybatis/mapper/M_WORKER*.xml" />
</bean>

<!-- 事務相關配置 -->
<tx:annotation-driven transaction-manager="transactionManager" order="1" />

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
	<property name="dataSource" ref="dataSource" />
</bean>

<!-- Mybatis Mapper掃描 -->
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
	<property name="annotationClass" value="org.springframework.stereotype.Repository" />
	<property name="basePackage" value="com.baidu.fsg.uid.worker.dao" />
	<property name="sqlSessionFactoryBeanName" value="sqlSessionFactory" />
</bean>

<!-- 資料源配置 -->
<bean id="dataSource" parent="abstractDataSource">
	<property name="driverClassName" value="${mysql.driver}" />
	<property name="maxActive" value="${jdbc.maxActive}" />
	<property name="url" value="${jdbc.url}" />
	<property name="username" value="${jdbc.username}" />
	<property name="password" value="${jdbc.password}" />
</bean>

<bean id="abstractDataSource" class="com.alibaba.druid.pool.DruidDataSource" destroy-method="close">
	<property name="filters" value="${datasource.filters}" />
	<property name="defaultAutoCommit" value="${datasource.defaultAutoCommit}" />
	<property name="initialSize" value="${datasource.initialSize}" />
	<property name="minIdle" value="${datasource.minIdle}" />
	<property name="maxWait" value="${datasource.maxWait}" />
	<property name="testWhileIdle" value="${datasource.testWhileIdle}" />
	<property name="testOnBorrow" value="${datasource.testOnBorrow}" />
	<property name="testOnReturn" value="${datasource.testOnReturn}" />
	<property name="validationQuery" value="${datasource.validationQuery}" />
	<property name="timeBetweenEvictionRunsMillis" value="${datasource.timeBetweenEvictionRunsMillis}" />
	<property name="minEvictableIdleTimeMillis" value="${datasource.minEvictableIdleTimeMillis}" />
	<property name="logAbandoned" value="${datasource.logAbandoned}" />
	<property name="removeAbandoned" value="${datasource.removeAbandoned}" />
	<property name="removeAbandonedTimeout" value="${datasource.removeAbandonedTimeout}" />
</bean>

<bean id="batchSqlSession" class="org.mybatis.spring.SqlSessionTemplate">
	<constructor-arg index="0" ref="sqlSessionFactory" />
	<constructor-arg index="1" value="BATCH" />
</bean>

@Resource
private UidGenerator uidGenerator;

@Test
public void testSerialGenerate() {
    // Generate UID
    long uid = uidGenerator.getUID();

    // Parse UID into [Timestamp, WorkerId, Sequence]
    // {"UID":"180363646902239241","parsed":{    "timestamp":"2017-01-19 12:15:46",    "workerId":"4",    "sequence":"9"        }}
    System.out.println(uidGenerator.parseUID(uid));

}

Leaf

Leaf

同時支援号段模式和

snowflake

算法模式，可以切換使用。

号段模式

各個業務不同的發号需求用biz_tag字段來區分，每個biz-tag的ID擷取互相隔離，互不影響。如果以後有性能需求需要對資料庫擴容，不需要上述描述的複雜的擴容操作，隻需要對biz_tag分庫分表就行。

DROP TABLE IF EXISTS `leaf_alloc`;

CREATE TABLE `leaf_alloc` (
  `biz_tag` varchar(128)  NOT NULL DEFAULT '' COMMENT '業務key',
  `max_id` bigint(20) NOT NULL DEFAULT '1' COMMENT '目前已經配置設定了的最大id',
  `step` int(11) NOT NULL COMMENT '初始步長，也是動态調整的最小步長',
  `description` varchar(256)  DEFAULT NULL COMMENT '業務key的描述',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '資料庫維護的更新時間',
  PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;

leaf.name=com.sankuai.leaf.opensource.test
#是否開啟号段模式
leaf.segment.enable=true
leaf.jdbc.url=jdbc:mysql://localhost:3306/leaf_alloc?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

key

參數其實就是路徑上對應的

leaf-segment-test

，也就是資料庫對應的

biz_tag

。

Leaf-snowflake方案

Leaf-segment方案可以生成趨勢遞增的ID，同時ID号是可計算的，不适用于訂單ID生成場景。

Leaf的snowflake模式依賴于ZooKeeper，不同于原始snowflake算法也主要是在workId的生成上，Leaf中workId是基于ZooKeeper的順序Id來生成的，每個應用在使用Leaf-snowflake時，啟動時都會都在Zookeeper中生成一個順序Id，相當于一台機器對應一個順序節點，也就是一個workId。

leaf.name=com.sankuai.leaf.opensource.test
# 關閉号段模式
leaf.segment.enable=false
leaf.jdbc.url=jdbc:mysql://localhost:3306/leaf_test?useUnicode=true&characterEncoding=utf8&characterSetResults=utf8
leaf.jdbc.username=root
leaf.jdbc.password=1234
#是否開啟雪花算法
leaf.snowflake.enable=true
leaf.snowflake.zk.address=127.0.0.1
leaf.snowflake.port=2181

http://localhost:8080/api/snowflake/get/key來擷取分布式遞增id

Tinyid

Tinyid會将可用号段加載到記憶體中，并在記憶體中生成ID，可用号段在首次擷取ID時加載，如目前号段使用達到一定比例時，系統會異步的去加載下一個可用号段，以此保證記憶體中始終有可用号段，以便在發号服務當機後一段時間内還有可用ID。

Tinyid

提供

http

和

tinyid-client

兩種方式接入。

tinyid

内部一共提供了四個

http

接口來擷取ID和号段。

nextId 、 nextIdSimple 都是擷取下一個ID
nextSegmentId、nextSegmentIdSimple 是擷取下一個可用号段
差別在于接口的傳回格式。

Http方式接入

CREATE TABLE `tiny_id_info` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  `biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '業務類型，唯一',
  `begin_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '開始id，僅記錄初始值，無其他含義。初始化時begin_id和max_id應相同',
  `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 '餘數',
  `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '建立時間',
  `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資訊表';
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);

# 目前token可以操作哪些業務的号段資訊
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可通路的業務類型辨別',
  `remark` varchar(255) NOT NULL DEFAULT '' COMMENT '備注',
  `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '建立時間',
  `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_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');

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

擷取分布式自增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

用戶端形式

重複Http方式操作，接下來引入依賴，配置參數。

<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
Long id =  TinyId . nextId( " test " );
// 按需批量分布式自增ID
List< Long > ids =  TinyId . nextId( " test " , 10 );

參考

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

美團Leaf源碼——号段模式源碼解析

美團Leaf源碼——snowflake模式源碼解析

UidGenerator

java面試之分布式ID

1. 分布式ID

2.分布式ID生成方式

UUID

基于資料庫自增ID

資料庫叢集模式

資料庫的号段模式

Redis模式

雪花算法

Uid-generator

Leaf

Tinyid

Http方式接入

用戶端形式

參考

繼續閱讀

Kafka：Topic概念與API介紹

ZooKeeper ： Curator架構之分布式屏障DistributedDoubleBarrier

RabbitMQ：交換機（fanout exchange）

Doris SQL 原了解析

ZooKeeper ： Curator架構之分布式鎖InterProcessMutex

2022秋招面經彙總1. 小米2. 滴滴轉正3. 映客

阿裡巴巴分布式服務架構 Dubbo 團隊成員梁飛專訪

資料遷移方法資料遷移原則資料遷移之雙寫方案資料遷移之級聯同步方案

微服務-性能壓測\緩存redis和分布式鎖redisson和SpringCache

Nacos 2.0 更新前後性能對比壓測

Spring資料和Redis

redis叢集資料一緻性_RedisRaft為Redis叢集帶來強大的資料一緻性

Centos7 下 Hadoop 2.6.4 分布式叢集環境搭建摘要叢集準備安裝JDK 安裝 Hadoop 2.6.4 部署 slaver1-slaver4 啟動 hadoop 叢集成功了

celery使用入門

MapReduce的幾個企業級經典面試案例MapReduce的幾個企業級經典面試案例