ID生成方案总结

分布式ID生成方案

  • UUID
  • 数据库自增
  • 号段模式
  • Redis实现
  • 雪花算法(SnowFlake)
  • 百度Uidgenerator
  • 美团Leaf
  • 滴滴TinyID

本文重点介绍能够ID自增的Leaf和TinyID

号段模式

这种模式也是现在生成分布式ID的一种方法,实现思路是会从数据库获取一个号段范围,比如[1,1000],生成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 :版本号,就像MVCC一样,可以理解为乐观锁
等ID都用了,再去数据库获取,然后更改最大值

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

优点:有比较成熟的方案,像百度Uidgenerator,美团Leaf
缺点:依赖于数据库实现

美团Leaf

Leaf 提供两种生成的ID的方式:号段模式(Leaf-segment)和snowflake模式(Leaf-snowflake)。你可以同时开启两种方式,也可以指定开启某种方式,默认两种方式为关闭状态。

git位置

GitHub - Meituan-Dianping/Leaf: Distributed ID Generate Service

介绍文档

https://github.com/Meituan-Dianping/Leaf/blob/master/README_CN.md

创建数据表

CREATE DATABASE leaf
CREATE TABLE `leaf_alloc` (
  `biz_tag` varchar(128)  NOT NULL DEFAULT '',
  `max_id` bigint(20) NOT NULL DEFAULT '1',
  `step` int(11) NOT NULL,
  `description` varchar(256)  DEFAULT NULL,
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;

insert into leaf_alloc(biz_tag, max_id, step, description) values('leaf-segment-test', 1, 2000, 'Test leaf Segment Mode Get Id')

获取项目

git clone git@github.com:Meituan-Dianping/Leaf.git

升级mysql驱动

如果连接的是mysql1.8以上,需要升级mysql驱动,分别是

Leaf/poe.xml以及 leaf_core/poe.xml

# Leaf/poe.xml
<mybatis-spring.version>1.2.5</mybatis-spring.version>

#leaf_core/poe.xml
 <dependency>
     <groupId>mysql</groupId>
     <artifactId>mysql-connector-java</artifactId>
      <version>8.0.25</version>
 </dependency>

修改配置

下面是号段模式的配置

leaf_server/resouces/leaf.properties

leaf.name=com.sankuai.leaf.opensource.test
leaf.segment.enable=true
leaf.jdbc.url=jdbc:mysql://127.0.0.1:3306/leaf?useSSL=false
leaf.jdbc.username=root
leaf.jdbc.password=123456

leaf.snowflake.enable=false
#leaf.snowflake.zk.address=
#leaf.snowflake.port=

打包

cd leaf
mvn clean install -DskipTests

运行

cd leaf-server
#mvn方式
mvn spring-boot:run
#脚本方式
sh deploy/run.sh 

测试

#segment
curl http://localhost:8080/api/segment/get/leaf-segment-test
#snowflake
curl http://localhost:8080/api/snowflake/get/test
监控页面
号段模式:http://localhost:8080/cache

#注意添加一个biz_type以后,10s以后生效

滴滴TinyID

github位置

GitHub - didi/tinyid: ID Generator id生成器

 介绍文档

Home · didi/tinyid Wiki · GitHub

获取项目

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

创建数据表

tinyid-server/db.sql

CREATE TABLE `tiny_id_info` (
  `id` bigint(20) 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');

修改配置

cd tinyid-server/src/main/resources/offline
vi application.properties

server.port=9999
server.context-path=/tinyid

batch.size.max=100000

#datasource.tinyid.names=primary
#如果希望数据库能够高可用,可以设置多个不同节点,两个节点上的数据保持一致。
#注意添加配置的时候,多个节点都要添加
datasource.tinyid.names=primary,secondary
datasource.tinyid.type=org.apache.tomcat.jdbc.pool.DataSource

datasource.tinyid.primary.driver-class-name=com.mysql.jdbc.Driver
datasource.tinyid.primary.url=jdbc:mysql://localhost:3306/db1?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8
datasource.tinyid.primary.username=root
datasource.tinyid.primary.password=123456
#datasource.tinyid.primary.testOnBorrow=false
#datasource.tinyid.primary.maxActive=10

datasource.tinyid.secondary.driver-class-name=com.mysql.jdbc.Driver
datasource.tinyid.secondary.url=jdbc:mysql://localhost:3306/db2?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8
datasource.tinyid.secondary.username=root
datasource.tinyid.secondary.password=123456
datasource.tinyid.secondary.testOnBorrow=false
datasource.tinyid.secondary.maxActive=10


打包

cd tinyid

mvn clean install -DskipTests

#或者

cd tinyid-server/
sh build.sh offline

运行

cd tinyid-server/
#sh build.sh offline
java -jar output/tinyid-server-xxx.jar

测试

nextId:
curl 'http://localhost:9999/tinyid/id/nextId?bizType=test&token=0f673adf80504e2eaa552f5d791b644c'
response:{"data":[2],"code":200,"message":""}

nextId Simple:
curl 'http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c'
response: 3

with batchSize:
curl 'http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c&batchSize=10'
response: 4,5,6,7,8,9,10,11,12,13

Get nextId like 1,3,5,7,9...
bizType=test_odd : delta is 2 and remainder is 1
curl 'http://localhost:9999/tinyid/id/nextIdSimple?bizType=test_odd&batchSize=10&token=0f673adf80504e2eaa552f5d791b644c'
response: 3,5,7,9,11,13,15,17,19,21

 

客户端使用

客户端打包

cd tinyid

mvn clean install -DskipTests

#tinyid-client\target\tinyid-client-0.1.0-SNAPSHOT.jar就是可以使用的客户端

客户端配置文件

tinyid_client.properties

将tinyid_client.properties放在resouces下面

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

使用

public class ClientTest {
    @Test
    public void testNextId() {
        for (int i = 0; i < 100000; i++) {
            Long id = TinyId.nextId("test_odd");
            System.out.println("current id is: " + id);
        }
    }
}

注意:每次重启程序,id就会往前加一个step,不管你有没有用完,如果程序经常重启,step不宜设置过大。但是step不宜设置过小,否则与数据库交互过于频繁。

来源:

8种分布式ID生成方案汇总 

<think>嗯,用户让我介绍分布式ID生成方案。我需要先理清楚分布式ID生成的基本概念和常见方法。首先,分布式系统中生成唯一ID的挑战是什么?传统的自增ID在单机数据库中可以保证唯一,但在分布式环境下,多节点同时生成ID时会有冲突的可能,所以需要一种分布式的解决方案。 接下来,常见的方案有哪些呢?我记得有UUID、数据库自增、Snowflake算法、Redis生成,还有像Leaf这样的开源项目。需要逐一分析它们的优缺点。比如UUID虽然简单,但过长且无序,可能影响数据库索引效率。数据库自增需要维护一个中央数据库,可能成为单点故障,性能也有瓶颈。Snowflake算法利用时间戳、机器ID和序列号,生成有序的ID,但机器ID的分配和管理需要额外处理。 然后,用户可能需要了解每个方案的具体实现细节。比如Snowflake的结构,时间戳占多少位,机器ID如何分配,序列号的作用是什么。还有可能遇到的问题,比如时钟回拨对Snowflake的影响,以及如何解决这个问题,比如使用NTP同步或者预留位处理。 另外,用户可能关心不同方案的优缺点比较,以及适用场景。比如高并发下哪种方案更合适,是否需要趋势递增的特性,对存储空间的要求等等。可能需要举例说明,比如订单ID、日志跟踪等不同场景下的选择。 还要注意用户可能对某些技术细节不太清楚,需要用通俗易懂的语言解释,避免使用过多专业术语。同时,结构要清晰,分点说明,方便用户理解。比如分方案介绍,每个方案的结构、流程、优缺点,最后总结对比。 最后,是否需要提到一些新的方案或者变种,比如改进版的Snowflake,或者结合数据库和缓存的方案,如Leaf-segment和Leaf-snowflake。可能还要提到第三方服务如美团的Leaf,百度的UidGenerator,避免重复造轮子。 需要检查是否符合用户给的系统级指令,比如数学公式是否正确用$包裹,独立公式用$$,中文回答,结构清晰。同时确保LaTeX语法正确,比如时间戳、机器ID和序列号的位数表示是否正确,使用等宽字体或者代码块显示可能更好,但用户要求用LaTeX的话,需要用数学公式格式。 总结思考步骤:先介绍分布式ID的需求和挑战,再分点讲解各方案的结构、流程、优缺点,最后对比总结,给出选型建议。确保每个部分都符合用户的格式要求,正确使用LaTeX,结构清晰。</think>以下是分布式ID生成方案的详细介绍,按常见方案分类说明: ### 一、需求背景 在分布式系统中,需要满足: 1. 全局唯一性 2. 趋势递增(利于数据库索引) 3. 高可用(QPS 10万+) 4. 可控制暴露信息(如避免连续数字暴露订单量) ### 二、常见方案对比 | 方案 | 优点 | 缺点 | |--------------------|-----------------------------|-----------------------------| | UUID | 简单、无中心化 | 无序、存储空间大(36字符) | | 数据库自增 | 绝对有序、易实现 | 存在单点故障风险、扩展性差 | | Snowflake | 高性能、可排序 | 依赖时钟、需管理机器ID | | Redis生成 | 高性能、可定制 | 依赖额外组件、维护成本高 | | Leaf-segment | 缓冲优化、高可用 | 需维护DB、存在号码段浪费 | ### 三、核心方案详解 #### 1. UUID $$ UUID示例:550e8400-e29b-41d4-a716-446655440000 $$ - 生成方式:标准RFC规范生成128位数字 - 缺点:无序性导致索引效率下降(B+树分裂) #### 2. 数据库自增 ```sql CREATE TABLE id_generator ( id int NOT NULL AUTO_INCREMENT, stub char(1) NOT NULL DEFAULT '', PRIMARY KEY (id), UNIQUE KEY stub (stub) ) ``` - 通过REPLACE INTO获取ID - 改进方案:多实例设置不同步长 $$ ID = n \times k + m $$ (n为实例数,k为步长,m为实例偏移量) #### 3. Snowflake算法 $$ ID = 时间戳 \times 2^{22} + 机器ID \times 2^{12} + 序列号 $$ - 位分配(64位): - 时间戳:41位(约69年) - 机器ID:10位(1024节点) - 序列号:12位(4096/ms) - 时钟回拨解决方案: - 物理时钟+逻辑时钟混合 - 故障时切换备用ID生成器 #### 4. Leaf方案(美团) **4.1 Leaf-segment** ```plantuml 客户端 -> Proxy: 获取ID段 Proxy -> DB: 更新max_id DB -> Proxy: 返回新号段 Proxy -> 客户端: 分配号段 ``` - 双Buffer优化:提前加载下一个号段 **4.2 Leaf-snowflake** - 改进点: - 使用ZK分配workerID - 时钟同步校验 - 异常时降级为号段模式 ### 四、选型建议 | 场景 | 推荐方案 | |----------------------|---------------------| | 中小型系统 | 改进版数据库自增 | | 高并发互联网业务 | Snowflake/Leaf | | 非结构化数据标识 | UUIDv4 | | 高可用性要求 | Redis集群+ Lua脚本 | ### 五、特殊场景处理 1. **环形缓冲区**:提前生成ID池应对突发流量 2. **业务标识嵌入**: $$ ID = 业务码 \times 10^n + 分布式ID $$ 3. **跨机房方案**:在机器ID中分配3位机房标识 ### 六、性能指标参考 - Snowflake单机吞吐量:约400万ID/秒 - Leaf-segment性能:1.2万QPS(号段长度1000) - Redis集群:可达10万+ QPS 建议根据实际业务规模选择方案,大型系统推荐优先考虑Snowflake及其改进方案
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值