业务ID常用生成方式

最新推荐文章于 2024-03-07 07:57:06 发布
最新推荐文章于 2024-03-07 07:57:06 发布
阅读量2.8k 收藏 4
点赞数 1
分类专栏： Java 文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_42586723/article/details/106499751
版权

业务ID常用生成方式

分布式ID产生原因

  • 业务量扩增

    1. 业务量很小时，采用单库单表支撑现有业务；

    2. 业务量较小时，采用主从同步读写分离；

    3. 业务量很大时，需要对数据库进行分库分表，此时需要有唯一ID来标识一条数据，如订单、优惠券都需要有唯一ID(分布式ID)来标识

分布式ID的生成特性

  • 全局唯一

    必须保证ID是全局性唯一

  • 高可用低延时

    ID生成响应要快，能够扛住高并发，延时足够低不至于成为业务瓶颈

  • 数字类型趋势递增

    从MySQL存储引擎考虑，后面的ID必须必前面的大，并需要保证写入数据的性能

  • 长度短

    能够提高查询效率，从MySQL数据库规范考虑，尤其是ID作为主键

  • 信息安全

    如果ID连续生成，会导致被猜出从而泄漏业务信息，所以需要无规则

分布式ID生成方式

UUID

  • 简介

    UUID具有全球唯一的特性，可以做分布式ID，但不推荐

  • 生成方式

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

  • 分析

    UUID不适用于实际的业务需求，像用作订单号UUID这样的字符串没有丝毫意义，看不出和订单相关的有用信息；而对于数据库来说用作业务主键ID，它不仅太长而且还是字符串，存储性能差查询也很耗时

  • 优点

    生成简单，本地生成无网络消耗，具有全球唯一性

  • 缺点

    长度过长16 字节128位，36位长度的字符串，存储以及查询对MySQL的性能消耗较大，MySQL官方明确建议主键要尽量越短越好，作为数据库主键 UUID 的无序性会导致数据位置频繁变动，严重影响性能

数据库自增ID

  • 简介

    基于数据库的auto_increment自增ID完全可以充当分布式ID，具体实现：需要一个单独的MySQL实例用来生成ID

  • 生成方式

    
  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本身就是系统瓶颈，不推荐

  • 优点

    实现简单，ID单调自增，数值类型查询速度快

  • 缺点

    DB单点存在宕机风险，无法扛住高并发场景

数据库多主模式

  • 简介

    此方式是对上面数据库自增ID的高可用优化，采用主从模式集群。也就是两个MySQL实例都能单独生产自增ID

    需要设置起始值和自增步长，避免生成重复ID

  • 生成方式

    1. MySQL_1配置
    
  set @@auto_increment_offset = 1; --起始值
  set @@auto_increment_increment = 2; --步长
    1. MySQL_2配置
    
  set @@auto_increment_offset = 2; --起始值
  set @@auto_increment_increment = 2; --步长
    1. 运行结果

    两个MySQL实例的自增ID分别是：

    1、3、5、7、9
    2、4、6、8、10

  • 分析

    如果集群后的性能还是扛不住高并发，就要进行MySQL扩容增加节点

    数据库扩容增加节点

    水平扩展的数据库集群，有利于解决数据库单点压力的问题，同时为了ID生成特性，将自增步长按照机器数量来设置。

    增加第三台MySQL实例需要人工修改一、二两台MySQL实例的起始值和步长，把第三台机器的ID起始生成位置设定在比现有最大自增ID的位置远一些，但必须在一、二两台MySQL实例ID还没有增长到第三台MySQL实例的起始ID值的时候，否则自增ID就要出现重复了，必要时可能还需要停机修改。

  • 优点

    解决DB单点问题

  • 缺点

    不利于后续扩容，而且实际上单个数据库自身压力还是大，依旧无法满足高并发场景。

号段模式

  • 简介

    号段模式是当下分布式ID生成器的主流实现方式之一，号段模式可以理解为从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如 (1,1000] 代表1000个ID，具体的业务服务将本号段，生成1~1000的自增ID并加载到内存。

  • 生成方式

    
  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 int(20) NOT NULL COMMENT '版本号',
    PRIMARY KEY (`id`)
  )

    biz_type ：代表不同业务类型

    max_id ：当前最大的可用id

    step ：代表号段的长度

    version ：是一个乐观锁，每次都更新version，保证并发时数据的正确性

  • 分析

    该批号段ID用完，再次向数据库申请新号段，对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

    获取分布式ID流程：

    1. 用户服务在注册一个用户时，需要一个用户ID；会请求生成ID服务(是独立的应用)的接口

    2. 生成ID的服务会去查询数据库，找到user_tag的id，现在的max_id为0，step=1000

    3. 生成ID的服务把max_id和step返回给用户服务，并且把max_id更新为max_id = max_id + step，即更新为1000

    4. 用户服务获得max_id=0，step=1000；

    5. 这个用户服务可以用[max_id + 1，max_id+step]区间的ID，即为[1，1000]

    6. 用户服务把这个区间保存到jvm中

    7. 用户服务需要用到ID的时候，在区间[1，1000]中依次获取id，可采用AtomicLong中的getAndIncrement方法。

    8. 如果把区间的值用完了，再去请求生产ID的服务的接口，获取到max_id为1000，即可以用[max_id + 1，max_id+step]区间的ID，即为[1001，2000]

  • 优点

    1. 扩张灵活，性能强能够撑起大部分业务场景。

    2. ID号码是趋势递增的，满足数据库存储和查询性能要求。

    3. 可用性高，即使ID生成服务器不可用，也能够使得业务在短时间内可用，为排查问题争取时间。

    4. 可以自定义max_id的大小，方便业务迁移，方便机器横向扩张。

  • 缺点

    由于多业务端可能同时操作，所以采用版本号version乐观锁方式更新

    1. ID号码不够随机，完整的顺序递增可能带来安全问题。

    2. DB宕机可能导致整个系统不可用，仍然存在这种风险，因为号段只能撑一段时间。

    3. 可能存在分布式环境各节点同一时间争抢分配ID号段的情况，这可能导致并发问题而出现ID重复生成

Redis

  • 简介

    Redis也同样可以实现，原理就是利用redis的 incr命令实现ID的原子性自增

  • 生成方式

    
  set seq_id 1     // 初始化自增ID为1

  incr seq_id      // 增加1，并返回递增后的数值

  • 分析

    用redis实现需要注意一点，要考虑到redis持久化的问题。redis有两种持久化方式RDB和AOF：

    1. RDB会定时打一个快照进行持久化，假如连续自增但redis没及时持久化，而这会Redis挂掉了，重启Redis后会出现ID重复的情况。

    2. AOF会对每条写命令进行持久化，即使Redis挂掉了也不会出现ID重复的情况，但由于incr命令的特殊性，会导致Redis重启恢复的数据时间过长。

  • 优点

    有序递增，可读性强。

    能够满足一定性能。

  • 缺点

    强依赖于Redis，可能存在单点问题。

    占用宽带，而且需要考虑网络延时等问题带来地性能冲击。

雪花算法（SnowFlake）

  • 简介

    雪花算法（Snowflake）是twitter公司内部分布式项目采用的ID生成算法

    Snowflake64bit

  • 生成方式

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

          /**
            * 小知识点：
            * 1 << 4 指将数字1左移4位
            *
            * 1. 首先将1转换为二进制0000 0000 0000 0000 0000 0000 0000 0001（1个字节8个bit位）
            * 2. 然后把该数字高位（左侧）的4个零移出，其他的数字都朝左平移4位，最后在低位（右侧）的4个空位补零
            * 3. 则得到的最终结果是0000 0000 0000 0000 0000 0000 0001 0000，则转换为十进制是16
            **/
          for (int i = 0; i < (1 << 4); i++) {
              //10进制
              System.out.println(snowFlake.nextId());
          }
      }
  }

  • 分析

    Snowflake生成的是Long类型的ID，一个Long类型占8个字节，每个字节占8比特，也就是说一个Long类型占64个比特。

    Snowflake ID组成结构：正数位（占1比特）+ 时间戳（占41比特）+ 机器ID（占5比特）+ 数据中心（占5比特）+ 自增值（占12比特），总共64比特组成的一个Long类型。

    1. 第一个bit位（1bit）：Java中long的最高位是符号位代表正负，正数是0，负数是1，一般生成ID都为正数，所以默认为0。

    2. 时间戳部分（41bit）：毫秒级的时间，不建议存当前时间戳，而是用（当前时间戳 - 固定开始时间戳）的差值，可以使产生的ID从更小的值开始；41位的时间戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年

    3. 工作机器id（10bit）：也被叫做workId，这个可以灵活配置，机房或者机器号组合都可以。

    4. 序列号部分（12bit），自增值支持同一毫秒内同一个节点可以生成4096个ID

    根据这个算法的逻辑，只需要将这个算法用Java语言实现出来，封装为一个工具方法，那么各个业务应用可以直接使用该工具方法来获取分布式ID，只需保证每个业务应用有自己的工作机器id即可，而不需要单独去搭建一个获取分布式ID的应用。理论上Snowflake算法方案的QPS大约为409.6w/s

  • 优点

    1. 每秒能够生成百万个不同的ID，性能佳。

    2. 时间戳值在高位，中间是固定的机器码，自增的序列在低位，整个ID是趋势递增的。

    3. 能够根据业务场景数据库节点布置灵活挑战bit位划分，灵活度高

  • 缺点

    强依赖于机器时钟，如果时钟回拨，会导致重复的ID生成，所以一般基于此的算法发现时钟回拨，都会抛异常处理，阻止ID生成，这可能导致服务不可用

百度 （Uidgenerator）

  • 简介

    uid-generator是由百度技术部开发，项目GitHub地址 https://github.com/baidu/uid-generator

  • 生成方式

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

  • 分析

    uid-generator是基于Snowflake算法实现的，与原始的snowflake算法不同在于，uid-generator支持自定义时间戳、工作机器ID和序列号等各部分的位数，而且uid-generator中采用用户自定义workId的生成策略。

    对于uid-generator ID组成结构：

    workId，占用了22个bit位，时间占用了28个bit位，序列化占用了13个bit位，需要注意的是，和原始的snowflake不太一样，时间的单位是秒，而不是毫秒，workId也不一样，而且同一应用每次重启就会消费一个workId

    uid-generator需要与数据库配合使用，需要新增一个WORKER_NODE表。当应用启动时会向数据库表中去插入一条数据，插入成功后返回的自增ID就是该机器的workId数据由host，port组成

滴滴出品（TinyID）

  • 简介

    Tinyid由滴滴开发，Github地址：https://github.com/didi/tinyid

    Tinyid是基于号段模式原理实现的与Leaf如出一辙，每个服务获取一个号段（1000,2000]、（2000,3000]、（3000,4000]
    tinyID生成方式

生成方式

  • Http方式

    1. 导入TInyid源码

    git clone https://github.com/didi/tinyid.git

    1. 创建数据表
    
  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信息表';

  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_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');
    1. 配置数据库
    
  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
    1. 启动tinyid-server后测试
    
  获取分布式自增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

  • tinyid-client(Java客户端)

    1. 重复Http方式的（2）（3）操作

    2. 引入依赖

    
  <dependency>
      <groupId>com.xiaoju.uemc.tinyid</groupId>
      <artifactId>tinyid-client</artifactId>
      <version>${tinyid.version}</version>
  </dependency>
    1. 配置文件
    
  tinyid.server =localhost:9999
  tinyid.token =0f673adf80504e2eaa552f5d791b644c

    test 、tinyid.token是在数据库表中预先插入的数据，test 是具体业务类型，tinyid.token表示可访问的业务类型

    1. 测试方式
    
  // 获取单个分布式自增ID
  Long id =  TinyId.nextId("test");

  // 按需批量分布式自增ID
  List<Long> ids =  TinyId.nextId("test" ,10);

分析

Tinyid是基于号段模式原理实现的与Leaf如出一辙，每个服务获取一个号段（1000,2000]、（2000,3000]、（3000,4000]

美团（Leaf）

  • 简介

    Leaf由美团开发，github地址：https://github.com/Meituan-Dianping/Leaf

    Leaf同时支持号段模式和snowflake算法模式，可以切换使用

号段模式

  • 生成方式

    1. 先导入源码 https://github.com/Meituan-Dianping/Leaf

    2. 在建一张表leaf_alloc

    
  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;
    1. 然后在项目中开启号段模式，配置对应的数据库信息，并关闭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=
    1. 启动leaf-server 模块的 LeafServerApplication

    号段模式获取分布式自增ID的测试url ：http：//localhost：8080/api/segment/get/leaf-segment-test

    监控号段模式：http://localhost:8080/cache

  • 分析

    美团技术团队Leaf-segment对此做了优化，将获取一个号段的方式优化成获取两个号段，在一个号段用完之后不用立马去更新号段，还有一个缓存号段备用，这样能够有效解决这种冲突问题，而且采用双buffer的方式，在当前号段消耗了10%的时候就去检查下一个号段有没有准备好，如果没有准备好就去更新下一个号段，当当前号段用完了就切换到下一个已经缓存好的号段去使用，同时在下一个号段消耗到10%的时候，又去检测下一个号段有没有准备好，如此往复。

    1. 当前获取ID在buffer1中，每次获取ID在buffer1中获取

    2. 当buffer1中的Id已经使用到了100，也就是达到区间的10%

    3. 达到了10%，先判断buffer2中有没有去获取过，如果没有就立即发起请求获取ID线程，此线程把获取到的ID，设置到buffer2中。

    4. 如果buffer1用完了，会自动切换到buffer2

    5. buffer2用到10%了，也会启动线程再次获取，设置到buffer1中

    6. 依次往返

  • 优点

    1. 基本的数据库问题都解决了，而且行之有效。

    2. 基于JVM存储双buffer的号段，减少了数据库查询，减少了网络依赖，效率更高。

  • 缺点

    1. segment号段长度是固定的，业务量大时可能会频繁更新号段，因为原本分配的号段会一下子用完。

    2. 如果号段长度设置的过长，但凡缓存中有号段没有消耗完，其他节点重新获取的号段与之前相比可能跨度会很大。

  • 其他

    针对上面的缺点，美团有重新提出动态调整号段长度的方案

    假设服务QPS为Q，号段长度为L，号段更新周期为T，那么Q * T = L。最开始L长度是固定的，导致随着Q的增长，T会越来越小。但是本方案本质的需求是希望T是固定的。那么如果L可以和Q正相关的话，T就可以趋近一个定值了。所以本方案每次更新号段的时候，会根据上一次更新号段的周期T和号段长度step，来决定下一次的号段长度nextStep，下面是一个简单的算法，意在说明动态更新的意思：

    
  T < 15min，nextStep = step * 2
  15min < T < 30min，nextStep = step
  T > 30min，nextStep = step / 2

snowflake模式

  • 生成方式

    1. 配置说明

    Leaf的snowflake模式依赖于ZooKeeper，不同于原始snowflake算法也主要是在workId的生成上，Leaf中workId是基于ZooKeeper的顺序Id来生成的，每个应用在使用Leaf-snowflake时，启动时都会都在Zookeeper中生成一个顺序Id，相当于一台机器对应一个顺序节点，也就是一个workId。

    1. 配置
    
  leaf.snowflake.enable=true
  leaf.snowflake.zk.address=127.0.0.1
  leaf.snowflake.port=2181
    1. 测试

    snowflake模式获取分布式自增ID的测试url：http://localhost:8080/api/snowflake/get/test

参考链接

https://www.cnblogs.com/chengxy-nds/p/12315917.html

https://www.cnblogs.com/huchong/p/11400888.html
Charles Yan
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
分布式ID生成器（雪花算法SpringBoot版）
11-06
全局唯一ID作为一种唯一标识来区分数据，可用作订单号、用户ID等。ID生成器是生成全局唯一ID的工具，可封装为一种基础服务为其他业务提供服务。因此此项目就是用springboot封装ID生成器，让各种业务系统调用
Java EE常用框架.xmind
06-19
Java EE常用框架 WebService 介绍 基于Web的服务。它使用Web(HTTP)方式，接收和响应外部系统的某种请求。从而实现远程调用 术语 XML. Extensible Markup Language －扩展性标记语言 WSDL – ...
架构设计 | 分布式业务系统中，全局ID生成策略
【积累】，是一个长期持续的过程。
04-28 318
Twitter公司开源的分布式ID生成算法策略，生成的ID遵循时间的顺序。1为位标识，始终为0，不可用；41位时间截，存储时间截的差值（当前时间截-开始时间截)；10位的机器标识，10位的长度最多支持部署1024个节点；12位序列，毫秒内的计数，12位的计数顺序号支持每个节点每毫秒产生4096个ID序号；SnowFlake的优点是，整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分)，并且效率较高。...
深入了解雪花算法ID生成过程
最新发布
qq_43108153的博客
03-07 932
雪花算法ID生成步骤
全局ID生成方式
qq_42757463的博客
08-23 138
在复杂的分布式系统中，需要对大量的数据和消息进行唯一标识，在设计的初期就要考虑到日后的数据量的级别，如果需要对数据库进行分库分表，就需要有一个全局唯一id来标识一条数据或记录。
什么是逻辑主键和业务主键
huangdingsheng的博客
03-10 9147
定义： 逻辑主键（surrogate key）：无意义的字段，即自增长字段，即identity。这其中还有一个选择GUID(Globally Unique Identifier)。 也叫代理主键。 业务主键（natrual key）：有意义的字段，比如身份证 ID。也叫自然主键 维基百科介绍： 在关系数据库设计中，业务主键是一个由以及真实存在于世界中的属性构成的键。业务...
切面+注解 实现对 业务id 验证是否存在
窃光者
05-29 439
@Override public ResultBean<Object> updateAuthenticationPersonalInfo( @RequestBody @ExistBusinessData(tableName = TableName.DeveloperInfo,fieldCondition = {FieldName.DeveloperIdId,Field...
分布式id、系统id、业务id以及主键之间的关系
yxg520s的博客
07-28 1442
而水平扩展的数据库，如Cassandra，MongoDB和Google Cloud Spanner等，通常会提供一个统一的接口，应用程序可以像访问一个单一的数据库一样访问它，由数据库系统自动处理数据的分布和路由。是的，水平划分和水平扩展的数据库（也称为分布式数据库或数据库分片）在很多方面是相似的，它们都是通过将数据分散到多个数据库或数据表中来提高系统的性能和可扩展性。可以按照用户ID进行拆分，比如将用户ID为奇数的用户的数据存储在一组数据库中，将用户ID为偶数的用户的数据存储在另一组数据库中。
分布式系统业务id生成
weixin_45476104的博客
04-27 128
分布式系统业务id生成方案
雪花算法原理：（订单类、合同类）业务生成字符串id的方法（二）
scholar_06的博客
06-07 67
一些订单类或者合同类的业务场景需求要生成包含时间信息、账套、订单类型、排列顺序等特征的字符串id。较第一种方法，效率更高了。
业务ID 生成规则
banghuan8748的专栏
05-10 1915
在实际业务中，是否碰到过这种场景： 我们需要一个单号，要在业务系统里面保证唯一，保证增长？ 在运营过程，需要知道业务单发生的时间，最好不用经过系统查找就知道发生的时间？ 在排障过程中，不用再次查找就知道，订单的一些信息？ 业务ID 经常需要生成以方便后续跟踪使用。一般需要满足以下特性： 1. 唯一性 2. 可阅读 3. 增长 4. 数字类型？ 5. 其他信息(pa...
在系统中生成业务ID的几种方法
lxlong
12-26 1155
在系统中，除了使用数据库表本身的Id，如何生成各种业务Id？一下记录几种生成Id的方式： 使用数据库表记录生成的Id，以MySQL为例： 1) 首先创建一个数据库表，来记录当前的业务Id CREATE TABLE `global_auto_number` ( `id` varchar(32) NOT NULL, `version_optimized_lock` int(1...
入门学习Linux常用必会60个命令实例详解doc/txt
06-09
这是因为Linux和许多版本的Unix一样，提供了虚拟控制台的访问方式，允许用户在同一时间从控制台（系统的控制台是与系统直接相连的监视器和键盘）进行多次登录。每个虚拟控制台可以看作是一个独立的工作站，工作台...
fibbery-commons:一些常用的实体类或者操作类
05-09
Snowflake算法生成的分布式高效ID 把时间戳，工作机器id，序列号组合在一起。 除了最高位bit标记为不可用以外，其余三组bit占位均可浮动，看具体的业务需求而定。默认情况下41bit的时间戳可以支持该算法使用到2082年...
Java基础之for循环中continue,break和return关键字作用
CharlesYan的博客
03-26 5981
continue,break和return关键字傻傻分不清楚
高并发解决方案之熔断处理
CharlesYan的博客
03-29 3618
高并发系统熔断技术选型经验分享
Java学习之InterruptedException异常处理方式
CharlesYan的博客
03-23 2587
中断异常是线程交互的一种方式，若是上层不能处理InterruptedException异常则不需要调用interrupt方法
分布式集群唯一序列号生成
06-12
在分布式集群中，需要生成唯一的序列号，可以考虑以下几种方式： 1. 基于数据库的自增序列：可以使用数据库的自增序列来生成唯一的序列号。在分布式集群中，可以设置不同的起始值和步长，从而保证每个节点生成的序列号不会重复。 2. 基于Redis的自增序列：Redis可以通过INCR命令来生成自增的序列号。在分布式集群中，可以使用Redis的分片功能，将不同的序列号分配到不同的节点上，从而保证每个节点生成的序列号不会重复。 3. 基于Snowflake算法的序列号生成器：Snowflake算法是Twitter开源的一个序列号生成算法，可以生成唯一的64位序列号。在分布式集群中，可以使用不同的数据中心ID和机器ID，从而保证每个节点生成的序列号不会重复。 4. 基于UUID的序列号生成器：UUID是一种全局唯一的标识符，可以通过Java的UUID类来生成唯一的序列号。在分布式集群中，可以使用不同的节点ID和时间戳，从而保证每个节点生成的序列号不会重复。 以上是一些常用的分布式集群唯一序列号生成方式，具体的选择需要根据业务场景和性能需求进行考虑。

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值