java面试之分布式ID

最新推荐文章于 2024-04-25 20:09:31 发布
最新推荐文章于 2024-04-25 20:09:31 发布
阅读量403 收藏
点赞数
文章标签： id 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ymn159/article/details/115766803
版权

1. 分布式ID

业务数据量不大时，单库单表完全可以支撑现有业务，数据再大一点MySQL主从同步读写分离也能应对。

随着数据日渐增长，需要对数据库进行分库分表，分库分表后需要有一个唯一ID来标识一条数据，此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。

  • 全局唯一：必须保证ID是全局性唯一的
  • 高性能：高可用低延时，ID生成响应要块
  • 好接入：秉着拿来即用的设计原则，在设计和实现上要尽可能简单
  • 高可用

2.分布式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台左右，预计未来会增加至百台。

在这里插入图片描述

应用

/**
 * 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

扆梦楠
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Redis解决雪花算法dataId和workId的自动选择问题
m0_37208669的博客
03-06 9883
文章目录前言算法 1 代码算法 2 代码 前言 雪花算法是分布式系统中常用的唯一 id 生成算法， 一般创建雪花算法的时候，依赖dataCenterId与workerId 这两个值的取值都为 0~31 之间的整型。 对于一个雪花算法的 id 生成器，需要设置这两个参数值。 如果在单实例中，这两个值随便怎么设置都是没问题的， 但是对于应用集群部署的时候，为了保证高可用，肯定需要多实例部署。 这个时候...
Java面试题之分布式事务篇
q66562636的博客
06-20 1395
实际面试中遇到，形式的话有书面解答也有口述。1)你是如何看待分布式系统，微服务架构的？2)你系统里是如何处理分布式事务的？分布式系统，微服务架构在16年开始火，但是真正的普及是18年，其中有多少公司尝试使用这种新的架构体系可能数不胜数，分布式系统与传统的单体集成系统的最大区别是分为多个业务子服务，这些子服务为一个大的业务服务，而这套系统就是所谓的分布式系统，很多的公司一般在拆分微服务的时候都是按业务拆分，比如订单服务，会员服务，商品服务等等，按具体的业务拆分成子系统即微服务，但是其带来的挑战也是巨大的，之前
(三)snowflake生成中要解决的问题
厚积薄发
03-25 1411
一,workid 的获取 1,直接写到配置文件中,比较low, 如果实例比较多, 简直是噩梦 2,借助数据库,每个节点启动的时候往同一个表中插入数据, 自增的序列号作为workid 3,借助zookeeper, 启动的时候通过向同一个目录下创建顺序节点, 用顺序号作为workid 4,通过节点的ip地址最后一组作为workid 二, 时钟回拨解决 1,关闭时钟同步，避免产生时钟同步问题，不过这个不太现实 2,记录下来上一次生成ID的时间，如果发现本次生成ID的时候，时间戳小于上次的时间戳，.
分布式ID
yangnk的技术记录
05-12 347
本文介绍常见分布式ID方案的实现和原理。分布式ID方案大致可以分为两类，一类的基于数据库的实现，规定起始位置和步长，来实现趋势递增，保障ID不会重叠。一类是类snowflake的实现，将固定位数的字符串划分为不同的段，每一段代表不同的含义，基本上分段中包括：机器序列、时间戳、自增序列，这种方案需要考虑时钟回拨的情况，同时可以通过双buffer的设计来改进ID生产单点性能不足的问题。
Java分布式ID
最新发布
zhangyan_1010的专栏
04-25 1347
分布式ID
关于工作流引擎的workid的设计
开源驰骋工作流引擎
09-04 1295
工作流引擎，工作流程快速开发平台， 关于WorkID的设计 workid也叫流程实例id, 理解清楚workid的整个过程有助于理解如何获得数据，以及相关流程引擎表，业务数据表的产生变化的过程。这里以开源的驰骋工作流程引擎ccflow，jflow为例说明workid的设计来说明问题 概要说明 工作流程引擎的WorkID,也叫流程实例的ID,他是一个Int64类型的，自动增长的数据类型，经过...
IdWork
weixin_60189432的博客
02-27 279
使用IdWorker工具类随机生成唯一id。该工具类是从mybatisplus的起步依赖中获取的，但当我们的项目工程中没有使用mp却需要一个可以实现自动生成id的方法的时候，可以使用该工具类。
最热门的Java 分布式面试题汇总
04-26
18. 分布式ID生成：可使用雪花算法、UUID、MongoDB自增ID、Twitter的Snowflake或分布式ID生成服务如Seq。 19. 分布式事务解决方案：两阶段提交、三阶段提交、Saga、分布式事务协调器（如X/Open XA）等。 20. 大...
Java高级面试第二套6.分库分表之后分布式下如何保证ID全局唯一性
03-19
c#、java、php等多语言解决方案源代码 Wafer - 快速构建具备弹性能力的微信小程序 https://github.com/tencentyun/wafer 重要： 1.第二步，可以在5分钟内实现； 2.成本3元（腾讯云支持微信小程序2017年推广期间，3...
最新整理Java面试题
04-30
- **分布式ID生成**：Snowflake、UUID、Twitter的Twitter Snowflake、以及基于数据库的自增ID。 - **分布式缓存**：Redis、Memcached的使用场景与操作，以及缓存穿透、缓存雪崩、缓存击穿问题的解决方案。 以上是...
Java面试专属视频
04-04
面试必考之HashMap源码分析与实现 ，微服务架构之Spring Cloud Eureka 场景分析与实战，高性能必学之Mysql主从架构实践 ，架构师不得不知道的Spring事物不能回滚的深层次原因 ，分库分表之后分布式下如何保证ID全局...
java面试常见问题.docx
06-25
面试中，候选人应具备解决数据库连接泄漏、MyBatis优化、高并发场景优化、分布式ID生成、分布式锁实现、Redis数据同步、秒杀限流、跨域请求处理、代码优化和系统性能调优等实际问题的能力。准备过程中，熟悉这些技术...
雪花算法简介
weixin_45483328的博客
06-22 2055
雪花算法生成ID长度为64bit 第1 位 为0 第2- 42 位 时间戳 第43 - 47 机器ID 第48 - 52 服务id 第 53 - 64位 序号
SnowFlake算法Java实现(雪花算法)生成分布式ID
鸟哥哥的专栏
08-26 2982
SnowFlake算法(雪花算法)java 生成分布式ID。SnowFlake 算法是 Twitter 开源的分布式唯一 ID 生成算法。雪花算法其具有高性能、低延迟、按时间趋势有序等特点。雪花算法理论支持每毫秒生成 4096 个不同数字，能够满足绝大多数高并发场景下的互联网应用。
mysql分布式主键生成器_分布式ID生成器Ray
weixin_29179311的博客
02-08 206
背景在应用程序中，经常需要全局唯一的ID作为数据库主键。我们需要什么样的ID生成器高性能 -> 1.生成性能高 2.插入性能高 3.索引性能高高可用 -> 1.依赖中间件要少 2.避免单节点问题不重复 -> 1.集群内全局不重复易使用 -> 1.接入简单 2.零学习成本语义性 -> 1.ID带有一些其它信息如何满足这几点要求生成性能高 -> 大多数时间为内存分配...
java idwork长度_java 字符串id
weixin_30839665的博客
03-04 308
Java FutureTaskimport java.util.ArrayList;import java.util.concurrent.Callable;import java.util.concurrent.FutureTask;public class Book {public Book() {Arr...文章开开心心过2018-01-09662浏览量你真的了解Python的字符串吗？它竟...
为什么驰骋工作流引擎的workid出现的不是连续的？workid的生成机制是什么？
开源的.net工作流程引擎,工作流程管理系统,bpm软件. http://ccflow.org
12-16 255
为什么驰骋工作流引擎的workid出现的不是连续的？workid的生成机制是什么？ 答: 1,驰骋工作流引擎的workid是一个int64 类型。 2,它是全局唯一的，每生成一个流程实例就会创建全局中一个不重复id. 3,产生workid的方法是BP.DA.DBAccess.GenerOID(). 4, 它的顺序号记录在 SELECT * FROM Sys_S...
【JAVA面试】分布式ID
Gangangan_的博客
05-11 741
分布式ID（Distributed ID）是在分布式系统中生成唯一标识符的一种技术。由于分布式系统中存在多个节点并行处理请求，为了避免不同节点生成相同的标识符，需要引入分布式ID来保证唯一性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值